Halting the Hacker - A Practical Guide to Computer Security

home *** CD-ROM | disk | FTP | other *** search

/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1504.txt < prev next >

Wrap

Text File | 1997-04-01 | 164KB | 3,692 lines

Network Working Group A. Oppenheimer Request for Comments: 1504 Apple Computer August 1993 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Introduction This memo is being distributed to members of the Internet community to fully document an Apple protocol that may be running over the Internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. About This Document This document provides detailed information about the AppleTalk Update-based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. The organization of this document has as its basis the three major components of AURP: AppleTalk tunneling, which allows AppleTalk data to pass through foreign networks and over point-to-point links the propagation of AppleTalk routing information between internet routers connected through foreign networks or over point-to-point links the presentation of AppleTalk network information by an internet router to nodes and other Phase 2-compatible routers on its local internet What This Document Contains The chapters of this document contain the following information: Chapter 1, "Introduction to the AppleTalk Update-Based Routing Protocol," introduces the three major components of AURP and the Oppenheimer [Page 1] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 key wide area routing enhancements that AURP provides to the AppleTalk routing protocols. Chapter 2, "Wide Area AppleTalk Connectivity," provides information about AppleTalk tunneling through IP internets and over point-to-point links. Chapter 3, "Propagating Routing Information With the AppleTalk Update-Based Routing Protocol," describes the essential elements of AURP, including the architectural model for update-based routing. This chapter provides detailed information about the methods that AURP uses to propagate routing information between internet routers connected through tunnels. Chapter 4, "Representing Wide Area Network Information," describes optional features of AURP-some of which can also be implemented on routers that use RTMP rather than AURP for routing-information propagation. It gives detailed information about how an exterior router represents imported network information to its local internet and to other exterior routers. It describes network hiding, device hiding, network-number remapping, clustering, loop detection, hop-count reduction, hop-count weighting, and backup paths. The Appendix, "Implementation Details," provides information about implementing AURP. What You Need to Know This document is intended for developers of AppleTalk wide area routing products. It assumes familiarity with the AppleTalk network system, internet routing, and wide area networking terms and concepts. Format of This RFC Document The text of this document has been quickly prepared for RFC format. However, the art is more complex and is not yet ready in this format. We plan to incorporate the art in the future. Consult the official APDA document, as indicated below, for the actual art. For More Information The following manuals and books from Apple Computer provide additional information about AppleTalk networks. You can obtain books published by Addison-Wesley at your local bookstore. Contact APDA, Apple's source for developer tools, to obtain technical reference materials for developers: Oppenheimer [Page 2] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 APDA Apple Computer, Inc. 20525 Mariani Avenue, M/S 33-G Cupertino, CA 95014-6299 These manuals provide information about some AppleTalk network products: The Apple Ethernet NB User's Guide explains how to install and use an Apple Ethernet NB Card and EtherTalk software on an AppleTalk network. The Apple InteroPoll Network Administrator's Guide describes how to perform maintenance and troubleshooting on an AppleTalk network using InteroPoll, a network administrator's utility program. The Apple Internet Router Administrator's Guide explains how to install the Apple Internet Router Basic Connectivity Package and how to use the Router Manager application program. It provides information about setting up the router, configuring ports to create local area and wide area internets, monitoring and troubleshooting router operation, and planning your internet. Using the AppleTalk/IP Wide Area Extension explains how to install and use the AppleTalk/IP Wide Area Extension for the Apple Internet Router. It provides information about tunneling through TCP/IP networks, configuring an IP Tunnel access method for an Ethernet or Token Ring port on the Apple Internet Router, troubleshooting IP tunneling problems, and configuring MacTCP. The AppleTalk Remote Access User's Guide explains how to use a Macintosh computer to communicate with another Macintosh computer over standard telephone lines to access information and resources at a remote location. The Apple Token Ring 4/16 NB Card User's Guide explains how to install and operate the card and TokenTalk software on a Token Ring network. The MacTCP Administrator's Guide, version 1.1, explains how to install and configure the MacTCP driver, which implements TCP/IP (Transmission Control Protocol/Internet Protocol) on a Macintosh computer. Oppenheimer [Page 3] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 The following books provide reference information about AppleTalk networks: The Advantages of AppleTalk Phase 2 provides a detailed description of the enhanced internetworking capabilities of AppleTalk Phase 2, and a brief guide to upgrading an AppleTalk internet to AppleTalk Phase 2. Available from Apple Computer. The AppleTalk Network System Overview provides a technical introduction to the AppleTalk network system and its protocol architecture. Published by Addison-Wesley Publishing Company. The AppleTalk Phase 2 Introduction and Upgrade Guide is a detailed guide to upgrading AppleTalk network hardware, drivers, and application programs to AppleTalk Phase 2, and briefly describes extensions to the AppleTalk network system that enhance its support for large networks. Available from Apple Computer. The AppleTalk Phase 2 Protocol Specification is an addendum to the first edition of Inside AppleTalk that defines AppleTalk Phase 2 extensions to AppleTalk protocols that provide enhanced AppleTalk addressing, routing, and naming services. Available from APDA. Inside AppleTalk, second edition, is a technical reference that describes the AppleTalk protocols in detail and includes information about AppleTalk Phase 2. Published by Addison-Wesley Publishing Company. The Local Area Network Cabling Guide provides information about network media, topologies, and network types. Available from Apple Computer. Planning and Managing AppleTalk Networks provides in-depth information for network administrators about planning and managing AppleTalk networks-including AppleTalk terms and concepts, and information about network services, media, topologies, security, monitoring and optimizing network performance, and troubleshooting. Published by Addison-Wesley Publishing Company. Understanding Computer Networks provides an overview of networking-including basic information about protocol architectures, network media, and topologies. Published by Addison-Wesley Publishing Company. The AppleTalk Update-Based Routing Protocol Specification is the official Apple specification of AURP. It includes the artwork currently missing from this document. Available from APDA. Oppenheimer [Page 4] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Table of Contents 1. Introduction to the AppleTalk Update-Based Routing Protocol 6 Wide area routing enhancements provided by AURP 6 2. Wide Area AppleTalk Connectivity 7 AppleTalk tunneling 7 IP tunneling 14 Point-to-point tunneling 17 3. Propagating Routing Information With the AppleTalk Update-Based Routing Protocol 18 AURP architectural model 18 Maintaining current routing information with AURP 20 AURP-Tr 21 One-way connections 22 Initial information exchange 22 Reobtaining routing information 28 Updating routing information 28 Processing update events 33 Router-down notification 38 Obtaining zone information 40 Hiding local networks from remote networks 44 AURP packet format 45 Error codes 55 4. Representing Wide Area Network Information 56 Network hiding 56 Device hiding 57 Resolving network-numbering conflicts 59 Zone-name management 65 Hop-count reduction 66 Routing loops 67 Using alternative paths 71 Network management 73 Appendix. Implementation Details 75 State diagrams 75 AURP table overflow 75 A scheme for updates following initial information exchange 75 Implementation effort for different components of AURP 76 Creating free-trade zones 77 Implementation details for clustering 78 Modified RTMP algorithms for a backup path 79 Security Considerations 82 Author's Address 82 Oppenheimer [Page 5] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 1. INTRODUCTION TO THE APPLETALK UPDATE-BASED ROUTING PROTOCOL The AppleTalk Update-based Routing Protocol (AURP) provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. AURP consists of three major components: AppleTalk tunneling through foreign network systems-for example, TCP/IP (Transmission Control Protocol/Internet Protocol) and over point-to-point links the propagation of routing information between internet routers connected through foreign network systems or over point-to-point links the presentation of AppleTalk network information by an internet router to nodes or to other Phase 2-compatible routers on its local internet-in other words, on the AppleTalk internet connected directly to the router Chapter 3, "Propagating Routing Information With the AppleTalk Update-Based Routing Protocol," describes the elements of AURP that are essential for a minimal implementation of AURP. AURP includes many optional features for the presentation of network information. You can implement many of these optional features on routers that use either AURP or RTMP (Routing Table Maintenance Protocol) for routing-information propagation. Figure 1-1 shows how the three major components of AURP interact. <<Figure 1-1 Major components of AURP>> Wide Area Routing Enhancements Provided by AURP AURP provides AppleTalk Phase 2-compatible routing for large wide area networks (WANs). Key wide area routing enhancements provided by AURP include: tunneling through TCP/IP internets and other foreign network systems point-to-point tunneling basic security-including device hiding and network hiding remapping of remote network numbers to resolve numbering conflicts Oppenheimer [Page 6] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 internet clustering to minimize routing traffic and routing- information storage requirements hop-count reduction to allow the creation of larger internets improved use of alternate paths through hop-count weighting and the designation of backup paths 2. WIDE AREA APPLETALK CONNECTIVITY This chapter describes the wide area connectivity capabilities provided by the AppleTalk Update-based Routing Protocol (AURP), including: AppleTalk tunneling tunneling through TCP/IP internets tunneling over point-to-point links AppleTalk Tunneling Tunneling allows a network administrator to connect two or more native internets through a foreign network system to form a large wide area network (WAN). For example, an AppleTalk WAN might consist of two or more native AppleTalk internets connected through a tunnel built on a TCP/IP internet. In such an AppleTalk WAN, native internets use AppleTalk protocols, while the foreign network system uses a different protocol family. A tunnel connecting AppleTalk internets functions as a single, virtual data link between the internets. A tunnel can be either a foreign network system or a point-to-point link. Figure 2-1 shows an AppleTalk tunnel. <<Figure 2-1 AppleTalk tunnel>> There are two types of tunnels: dual-endpoint tunnels, which have only two routers on a tunnel-for example, point-to-point tunnels multiple-endpoint tunnels-herein referred to as multipoint tunnels- which have two or more routers on a tunnel AURP implements multipoint tunneling by providing mechanisms for data encapsulation and the propagation of routing information to specific routers. Oppenheimer [Page 7] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Exterior Routers An AppleTalk router with a port that connects an AppleTalk internet to a tunnel is an exterior router. An exterior router always sends split-horizoned routing information to the other exterior routers on a multipoint tunnel. That is, an exterior router on a multipoint tunnel sends routing information for only its local internet to other exterior routers on that tunnel. An exterior router never exports routing information obtained from other exterior routers on the tunnel, because the exterior routers communicate their own routing information to one another. As shown in Figure 2-2, the absence or presence of redundant paths, or loops, across a tunnel changes the way an exterior router defines its local internet. For more information about redundant paths, see the section "Redundant Paths" in Chapter 4. If no loops exist across a tunnel, an exterior router's local internet comprises all networks connected directly or indirectly to other ports on the exterior router. When loops exist across a tunnel, an exterior router's local internet comprises only those networks for which the next internet router is not across a tunnel. Using this definition of a local internet, two exterior routers' local internets might overlap if loops existed across a tunnel. For more information about routing loops, see the section "Routing Loops" in Chapter 4. <<Figure 2-2 An exterior router's local internet>> An exterior router functions as an AppleTalk router within its local internet and as an end node in the foreign network system connecting AppleTalk internets. An exterior router uses RTMP to communicate routing information to its local internet, and uses AURP and the network-layer protocol of the tunnel's underlying foreign network system to communicate with other exterior routers connected to the tunnel. An exterior router encapsulates AppleTalk data packets using the headers required by the foreign network system, then forwards the packets to another exterior router connected to the tunnel. FORWARDING DATA: When forwarding AppleTalk data packets across a multipoint tunnel, an exterior router encapsulates the AppleTalk data packets in the packets of the tunnel's underlying foreign network system by adding the headers required by that network system adds an AURP-specific header-called a domain header-immediately preceding each AppleTalk data packet Oppenheimer [Page 8] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 A domain header contains additional addressing information-including a source domain identifier and destination domain identifier. For more information about domain headers, see the sections "AppleTalk Data-Packet Format" and "AppleTalk Data-Packet Format for IP Tunneling" later in this chapter. For detailed information about domain identifiers, see the section "Domain Identifiers" later in this chapter. Before forwarding a data packet to a network in another exterior router's local internet, an exterior router must obtain the foreign- protocol address of the exterior router that is the next internet router in the path to the packet's destination network. The exterior router then sends the packet to that exterior router's foreign- protocol address using the network-layer protocol of the foreign network system. The exterior router need not know anything further about how the packet traverses this virtual data link. Once the destination exterior router receives the packet, it removes the headers required by the foreign network system and the domain header, then forwards the packet to its destination in the local AppleTalk internet. If the length of an AppleTalk data packet in bytes is greater than that of the data field of a foreign-protocol packet, a forwarding exterior router must fragment the AppleTalk data packet into multiple foreign-protocol packets, then forward these packets to their destination. Once the destination exterior router receives all of the fragments that make up the AppleTalk data packet, it reassembles the packet. CONNECTING MULTIPLE TUNNELS TO AN EXTERIOR ROUTER: An exterior router can also connect two or more multipoint tunnels. As shown in Figure 2-3, when an exterior router connects more than one multipoint tunnel, the tunnels can be built on any of the following: the same foreign network system different foreign network systems similar, but distinct foreign network systems <<Figure 2-3 Connecting multiple tunnels to an exterior router>> Whether the tunnels connected to an exterior router are built on similar or different foreign network systems, each tunnel acts as an independent, virtual data link. As shown in Figure 2-4, an exterior router connected to multiple tunnels functions logically as though it were two or more exterior routers connected to the same AppleTalk Oppenheimer [Page 9] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 network, with each exterior router connected to a different tunnel. <<Figure 2-4 An exterior router connected to multiple tunnels>> Fully Connected and Partially Connected Tunnels An AppleTalk multipoint tunnel functions as a virtual data link. AURP assumes full connectivity across a multipoint tunnel-that is, all exterior routers on such a tunnel can communicate with one another. An exterior router always sends split-horizoned routing information to other exterior routers on a multipoint tunnel. That is, an exterior router on a multipoint tunnel sends routing information for only its local internet to other exterior routers on that tunnel. An exterior router never exports routing information obtained from other exterior routers on the tunnel, because exterior routers communicate their routing information to one another. If all exterior routers connected to a multipoint tunnel are aware of and can send packets to one another, that tunnel is fully connected. If some of the exterior routers on a multipoint tunnel are not aware of one another, the tunnel is only partially connected. Figure 2-5 shows examples of a fully connected tunnel, a partially connected tunnel, and two fully connected tunnels. <<Figure 2-5 Fully connected and partially connected tunnels>> In the second example shown in Figure 2-5, the network administrator may have connected the tunnel partially for one of these reasons: to prevent the local internets connected to exterior routers A and C from communicating with one another, while providing full connectivity between the local internets connected to exterior router B and the local internets connected to both exterior routers A and C because local internets connected to exterior routers A and C need access only to local internets connected to exterior router B-not to each other's local internets because exterior routers A and C-which should be aware of one another-were misconfigured Generally, an exterior router cannot determine whether a multipoint tunnel is fully connected or partially connected. In the second example in Figure 2-5, exterior router B does not know whether exterior routers A and C are aware of one another. However, exterior Oppenheimer [Page 10] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 router B must assume that the tunnel is fully connected, and that exterior routers A and C can exchange routing information. An exterior router should never forward routing information received from other exterior routers back across the tunnel. It should always send split-horizoned routing information to other exterior routers. If connecting exterior routers A and C directly would be either expensive or slow, a network administrator could instead establish two independent multipoint tunnels-one connecting exterior routers A and B, another connecting exterior routers B and C-as shown in the third example in Figure 2-5. Exterior routers A and C could then establish connectivity by routing all data packets forwarded by one to the other through exterior router B. Hiding Local Networks From Tunnels When configuring a tunneling port on an exterior router, a network administrator can provide network-level security to a network in the exterior router's local internet by hiding that network. Hiding a specific network in the exterior router's local internet prevents internets across a multipoint tunnel from becoming aware of the presence of that network. When the exterior router exchanges routing information with other exterior routers connected to the tunnel, it exports no information about any hidden networks to the exterior routers from which the networks are hidden. An administrator can specify that certain networks in the exterior router's local internet be hidden from a specific exterior router connected to the tunnel or from all exterior routers on the tunnel. Nodes on the local internet of an exterior router from which a network is hidden cannot access that network. Neither the zones on a hidden network nor the names of devices in those zones appear in the Chooser on computers connected to such an internet. When a network is hidden, its nodes are also unable to access internets from which the network is hidden. If a node on a hidden network sends a packet across a tunnel to a node on an internet from which it is hidden, even if the packet arrives at its destination, the receiving node cannot respond. The exterior router connected to the receiving node's internet does not know the return path to the node on the hidden network. Thus, it appears to the node on the hidden network that the node to which it sent the packet is inaccessible. ADVANTAGES AND DISADVANTAGES OF NETWORK HIDING: Network hiding provides the following advantages: On large, global WANs, a network administrator can configure network-level security for an organization's internets. Oppenheimer [Page 11] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 It reduces the amount of network traffic across both a tunnel and the internets connected to that tunnel. Network hiding has the following disadvantages: Nodes on hidden networks have limited access to internets across a tunnel. AppleTalk networking software running on a node on a hidden network lists all of the AppleTalk zone names exported by exterior routers connected to a tunnel, but may list the names of only some or none of the devices in those zones. It cannot list the names of devices that are unable to respond to Name Binding Protocol (NBP) lookups originating from a node on a hidden network. Domain Identifiers Exterior routers assign a unique domain identifier to each AppleTalk internet, or domain. Domain identifiers enable exterior routers on a multipoint tunnel to distinguish individual AppleTalk internets in a wide area internet from one another. The definition of an AppleTalk domain identifier is extensible to allow for future use when many additional types of AppleTalk tunnels and tunneling topologies may exist: Under the current version of AURP, each exterior router connected to a multipoint tunnel assigns a domain identifier to its local AppleTalk internet that uniquely identifies that internet on the tunnel. If redundant paths connect an AppleTalk internet through more than one exterior router on a tunnel, each exterior router can assign a different domain identifier to that internet, or AppleTalk domain, as shown in Figure 2-6. Under future routing protocols, a domain identifier will define the boundaries of an AppleTalk domain globally-for all exterior routers. Thus, a domain identifier will be unique among all domains in a wide area internet. All exterior routers within a wide area internet will use the same domain identifier for a given AppleTalk internet, as shown in Figure 2-6. <<Figure 2-6 Domain identifiers>> To simplify an exterior router's port configuration, a parameter that is already administrated-such as a node address-can serve as the basis for an exterior router's domain identifier. Oppenheimer [Page 12] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 GENERAL DOMAIN-IDENTIFIER FORMAT: Figure 2-7 shows the general form of a domain identifier. <<Figure 2-7 General domain-identifier format>> The general domain identifier (DI) consists of the following fields: Length: Byte 1 represents the length of the DI in bytes, not including the length byte. A DI must consist of an even number of bytes. Thus, the length byte is always an odd-numbered byte. The length field permits tunneling through foreign network systems that have addresses of any length-including the long addresses characteristic of X.25 and OSI. The value of the length byte varies, depending on the format of the DI. Authority: Byte 2 indicates the authority that administrates the identifier bytes of the DI. At present, Apple has defined only two authority-byte values: $01-indicates that the subsequent bytes correspond to a unique, centrally administrated IP address $00-the null DI-indicates that no additional bytes follow All other authority-byte values are reserved and should not be used. Identifier: The identifier field starts at byte 3 and consists of a variable number of bytes of the type indicated by the authority byte. NULL DOMAIN-IDENTIFIER FORMAT: The use of a null domain identifier is appropriate only when there is no need to distinguish the domains connected to a tunnel-for example, where a tunnel exists within a single internet-or for a point-to-point link. Figure 2-8 shows the null form of a domain identifier. <<Figure 2-8 Null domain-identifier format>> A null domain identifier consists of the following bytes: Length: Byte 1 contains the value $01, defining the length of the null DI as one byte. Authority: Byte 2 contains the value $00, indicating a null DI. AppleTalk Data-Packet Format Part of the format of an AppleTalk data packet sent across a multipoint tunnel or a point-to-point link depends on the underlying Oppenheimer [Page 13] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 foreign network system. The headers required by a foreign-network protocol always precede an AppleTalk data packet sent across a multipoint tunnel. A domain header generally immediately precedes the AppleTalk data packet. Figure 2-9 shows the format of an AppleTalk data packet preceded by a domain header. <<Figure 2-9 AppleTalk data-packet format with a domain header>> A domain header consists of the following fields: Destination DI: The length of the destination DI field in bytes depends on the type of DI. Source DI: The length of the source DI field in bytes depends on the type of DI. Version number: The version number field is two bytes in length and currently contains the value 0001. Reserved: The two-byte field that follows the version number field is reserved for future use and is set to 0000. Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data-distinguishing it from other data, such as routing data. In the future, Apple may define other values for this field. An AppleTalk data packet does not require a domain header if it is sent across a multipoint tunnel or point-to-point link that provides separate channels for data and routing packets the domain header's destination DI and source DI fields would both contain null DIs Omitting a domain header reduces overhead associated with the exchange of routing information, without any loss of routing information. Figure 2-10 shows the format of an AppleTalk data packet without a domain header. <<Figure 2-10 AppleTalk data-packet format without a domain header>> IP Tunneling The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite is a widely used communications standard that provides interoperability among computers from various vendors, including Apple, IBM, Digital Equipment Corporation, Sun, and Hewlett-Packard. Oppenheimer [Page 14] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Descriptions of three of the most important TCP/IP protocols follow: The Transmission Control Protocol (TCP) is a transport-layer protocol that provides reliable data transmission between processes-that is, between programs that communicate with one another. This connection-oriented, byte-stream protocol ensures error-free, sequential data delivery, without loss or duplication. The User Datagram Protocol (UDP) is a transport-layer protocol that provides best-effort, low-overhead interprocess data transmission. This datagram-oriented protocol allows higher-layer protocols that do not require reliability to transmit data without incurring the overhead associated with TCP. UDP does no error checking, does not acknowledge its successful receipt of data, and does not sequence incoming messages. UDP messages may be lost, duplicated, or improperly sequenced. The Internet Protocol (IP) is a network-layer protocol that provides connectionless, best-effort datagram delivery across multiple networks. Each host on a TCP/IP network has a unique, centrally administrated internet address, called an IP address, that identifies the node. The header of an IP datagram contains its source and destination IP addresses, allowing any host to route a datagram to its destination. TCP/IP provides connectivity between many different network types that use data frames of various sizes. Therefore, IP can fragment a datagram before sending it across an internet. Datagram fragments can fit into data frames of any size. Once all of a datagram's fragments reach their destination, IP reassembles the datagram. Protocols in higher layers pass data to TCP or UDP for delivery to peer processes. TCP and UDP encapsulate the data in segments, using the appropriate headers, then pass the segments to IP. IP further encapsulates the data in IP datagrams, determines each datagram's path to its destination, and sends the datagrams across the internet. Figure 2-11 shows how the TCP/IP family of protocols conforms to the Open Systems Interconnection (OSI) model. <<Figure 2-11 TCP/IP protocol stack and the OSI model>> Exterior routers that connect AppleTalk internets through a TCP/IP tunnel are configured as nodes on both an AppleTalk internet and on the TCP/IP internet. Thus, an exterior router on a TCP/IP tunnel is also an IP end node in the TCP/IP network system. Exterior routers use the TCP/IP internet only to exchange AppleTalk routing information and AppleTalk data packets with one another. An exterior router encapsulates AppleTalk data packets in IP datagrams before Oppenheimer [Page 15] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 sending them across the TCP/IP internet to a forwarding exterior router, which decapsulates the packets, then forwards them to their destination AppleTalk networks. IP Domain-Identifier Format Under the current version of AURP, exterior routers on IP tunnels must use domain identifiers that are based on IP addresses. An exterior router on an IP tunnel derives its domain identifier from its IP address. Thus, a network administrator does not need to configure an exterior router's domain identifier. Figure 2-12 shows the IP form of a domain identifier. <<Figure 2-12 IP domain-identifier format>> An IP domain identifier consists of the following fields: Length: Byte 1 contains the value $07, defining the length of the IP DI as seven bytes. Authority: Byte 2 contains the value $01, indicating that the remainder of the DI is based on an IP address. Distinguisher: Bytes 3 and 4 are reserved for future use and are set to 0 ($00). IP address: Bytes 5 through 8 contain the four-byte IP address of either the sending or the receiving exterior router. NOTE: Future versions of AURP will allow exterior routers to usealternative formats for domain identifiers, even on IP tunnels. AppleTalk Data-Packet Format for IP Tunneling The following protocol headers precede an AppleTalk data packet that is forwarded across an IP tunnel by an exterior router: a data-link header an IP header a User Datagram Protocol (UDP) header a domain header An exterior router encapsulates AppleTalk data packets in UDP packets when forwarding them through its UDP port 387, across an IP tunnel, to UDP port 387 on another exterior router. When encapsulating data Oppenheimer [Page 16] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 packets, an exterior router should always use UDP checksums. When a destination exterior router receives the UDP packets at UDP port 387, it decapsulates the packets. A domain header consists of the following fields: Destination DI: This field contains the DI of the exterior router to which a packet is being forwarded. Source DI: This field contains the DI of the exterior router that is forwarding a packet. Version number: The version number field is two bytes in length and currently contains the value 0001. Reserved: The two-byte field that follows the version number field is reserved for future use and is set to 0000. Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data-distinguishing it from other data, such as routing data. An AppleTalk data packet consists of a domain header and AppleTalk data. Figure 2-13 shows the format of an AppleTalk data packet forwarded across an IP tunnel. <<Figure 2-13 AppleTalk data packet forwarded across an IP tunnel>> Point-to-Point Tunneling In point-to-point tunneling, two remote AppleTalk local area networks (LANs) connected to half-routers communicate with one another over a point-to-point link. A point-to-point link may consist of modems communicating over a standard telephone line or a leased line, such as a T1 line. Figure 2-14 shows an example of point-to-point tunneling. <<Figure 2-14 Point-to-point tunneling>> Generally, exterior routers use null domain identifiers on point-to- point links, because there is no IP address to be administrated and the opposite end of the tunnel is already uniquely identified. However, an exterior router may use other domain-identifier formats. Point-to-Point Protocol The Point-to-Point Protocol (PPP) is a data-link-layer protocol that provides a standard method of encapsulating and decapsulating Oppenheimer [Page 17] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 network-layer protocol information, and transmitting that information over point-to-point links. PPP includes an extensible Link Control Protocol (LCP) and a suite of Network Control Protocols (NCPs) that configure, enable, and disable various network-layer protocols. The AppleTalk Control Protocol (ATCP) is a PPP NCP for AppleTalk protocols. ATCP configures, enables, and disables the AppleTalk network-layer protocol DDP on the half-router at each end of a point-to-point link. ATCP also specifies the protocol that a half- router uses to propagate routing information-for example, AURP. When using AURP for routing-information propagation, a half-router uses a specific PPP protocol type to identify AURP routing-information packets-that is, packets preceded by a domain header. PPP provides separate channels for AppleTalk data packets and AppleTalk routing- information packets. Thus, a half-router can use DDP encapsulation to send AppleTalk data packets without including their domain headers. When using AURP, a half-router should accept both AppleTalk data packets that are preceded by domain headers and DDP-encapsulated packets. NOTE: The Request for Comments (RFC) 1378, "The PPP AppleTalk Control Protocol (ATCP)," provides a detailed specification of ATCP, as well as information about using PPP to send AppleTalk data. 3. PROPAGATING ROUTING INFORMATION WITH THE APPLETALK UPDATE-BASED ROUTING PROTOCOL This chapter describes the required elements of AURP. It provides detailed information about using the AppleTalk Update-based Routing Protocol (AURP) to propagate routing information between AppleTalk exterior routers connected through a foreign network or over a point-to-point link, and includes information about the AURP architectural model one-way connections exchanging routing information updating routing information notifying other exterior routers that an exterior router is going down obtaining zone information packet formats Oppenheimer [Page 18] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 error codes AURP Architectural Model AURP provides the functionality of the Routing Table Maintenance Protocol (RTMP) and the Zone Information Protocol (ZIP) while eliminating most of the routing traffic generated by these protocols. Figure 3-1 shows the architectural model for AURP. <<Figure 3-1 AURP architectural model>> Generally, an AppleTalk router uses RTMP and ZIP to maintain routing information, and sends RTMP data packets, ZIP Queries, and ZIP Replies out its ports. However, if one of the router's ports is connected to an AppleTalk tunnel, the architectural model for the router's central routing module becomes more complex. Logically, the central routing module in an exterior router communicates RTMP and ZIP information to an RTMP/ZIP-to-AURP conversion module, which sends AURP data packets out the tunneling port. RTMP/ZIP-to-AURP Conversion Module The RTMP/ZIP-to-AURP conversion module maintains split-horizoned routing-table information and network number-to-zone name mappings for each exterior router on the tunnel-that is, a copy of the routing information for each exterior router's local internet. Figure 3-2 shows the architectural components of the RTMP/ZIP-to-AURP conversion module. <<Figure 3-2 RTMP/ZIP-to-AURP conversion module architecture>> The AURP module of the conversion module obtains routing information from the other exterior routers on the tunnel, then periodically updates the routing-table information and the mappings in the conversion module. The RTMP module passes this routing-table information to the exterior router's central routing module. Logically, the RTMP module generates an RTMP data packet for each exterior router on the tunnel every ten seconds-the RTMP retransmission time-then passes the packet to the central routing module. The RTMP/ZIP-to-AURP conversion module also maintains a split- horizoned copy of the routing information maintained by the exterior router in which it resides. Logically, the conversion module obtains the routing information from RTMP data packets and ZIP Replies sent by the exterior router's central routing module, then updates the routing information in the conversion module. Oppenheimer [Page 19] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 The AURP module exports routing information about its local AppleTalk internet to other exterior routers on the tunnel. AURP Transport Layering AURP can propagate routing information between exterior routers using a simple, reliable transport based on an underlying datagram service-such as the default transport-layer service for AURP, AURP-Tr. See the section "AURP-Tr," later in this chapter, for more information. a more complex transport-layer service-such as TCP Figure 3-3 shows the AURP transport-layering model. <<Figure 3-3 AURP transport-layering model>> Maintaining Current Routing Information With AURP AURP allows exterior routers to maintain current routing information for other exterior routers on a tunnel by supporting the reliable, initial exchange of split-horizoned routing information - that is, the routing information for an exterior router's local internet reliable updates to that information whenever it changes If an internet topology does not change, AURP generates significantly less routing traffic than RTMP and ZIP. Thus, an administrator can connect very large AppleTalk internets through a tunnel, and the resulting internet generates little or no routing traffic on the tunnel. When an exterior router discovers another exterior router on the tunnel-that is, a peer exterior router-it can request that exterior router to send its routing information. In a reliable, initial exchange of split-horizoned routing information, the peer exterior router returns its network-number list. The peer exterior router also returns each connected network's zone information in an unsequenced series of zone-information packets. If the exterior router requesting the routing information does not receive complete zone information for a network, it must retransmit requests for zone information until it receives the information. Once an exterior router requesting routing information from a peer exterior router has received that exterior router's network-number Oppenheimer [Page 20] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 list and complete zone information, it typically requests the peer exterior router to notify it of any changes to that routing information. The peer exterior router then provides the requesting exterior router with reliable updates to its routing information- however, it sends no other routing information. Notifying Other Exterior Routers of Events If an exterior router has requested notification of changes in another exterior router's split-horizoned routing information, that exterior router must notify the requesting exterior router of any event that changes its routing information. Thus, an exterior router must send updated routing information to the requesting exterior router whenever any of the following events occur: the addition of a new, exported network-that is, a network that is not hidden-to the exterior router's local internet and, consequently, to its routing table a change in the path to an exported network that causes the exterior router to access that network through its local internet rather than through a tunneling port the removal of an exported network from the exterior router's routing table because a network in the exterior router's local internet has gone down a change in the path to an exported network that causes the exterior router to access that network through a tunneling port rather than through its local internet a change in the distance to an exported network a change to a zone name in the zone list of an exported network- an event not currently supported by ZIP or the current version of AURP the exterior router goes down or is shut down Routing-information updates allow an exterior router to maintain accurate, split-horizoned routing information for a peer exterior router on a tunnel. AURP-Tr AURP-Tr, the default transport-layer service for AURP, provides a simple, reliable transport that is based on an underlying datagram service. When using AURP-Tr, only one sequenced transaction can be Oppenheimer [Page 21] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 outstanding, or unacknowledged, at a time-greatly simplifying the implementation of AURP, without limiting its functionality. One-Way Connections A one-way connection is an asymmetrical link between a data sender and a data receiver that are using AURP-Tr, in which an exterior router functioning as a data sender sends a sequenced, reliable, unidirectional data stream to an exterior router functioning as a data receiver. An exterior router can send routing information over a one-way connection as sequenced data transaction data Sequenced data is data sent in sequence by the data sender and delivered reliably to the data receiver. Typically, the sending of sequenced data is unprovoked-that is, it is not requested by a data receiver. However, a data receiver can request sequenced data. Figure 3-4 shows sequenced data being sent across a one-way connection. <<Figure 3-4 Sequenced data on a one-way connection>> Transaction data-also referred to as out-of-band data-is data sent unsequenced by the data sender through a linked request/response transaction that is initiated by the data receiver. The data receiver can use a one-way connection to request transaction data from the data sender. If the data receiver does not receive a response, it must retransmit its request. Figure 3-5 shows a one-way connection on which the data receiver requests transaction data from the data sender. <<Figure 3-5 Request for transaction data on a one-way connection>> Generally, communication between two exterior routers is bidirectional-that is, two one-way connections exist between the exterior routers, with each exterior router acting as the data sender on one connection and the data receiver on the other. Thus, each exterior router can send its routing information to the other. Initial Information Exchange When an AppleTalk exterior router discovers another exterior router on the tunnel, it uses the underlying transport-layer service to open a connection with that exterior router. When using AURP-Tr, an exterior router opens this connection as a one-way connection. Oppenheimer [Page 22] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Open Request Packet Once the data receiver opens a connection using the underlying transport, the data receiver sends an Open Request packet, or Open- Req, to the data sender. An Open-Req packet includes the following information: Send update information flags: The states of the four send update information (SUI) flags indicate whether the data sender should send various types of update information over the connection. Typically, the four SUI flags are set to 1. Version number: The version number field indicates the version of AURP used by the data receiver. The current version number of AURP is 1. Data field: The optional data field allows exterior routers with capabilities beyond those described in this document to notify other exterior routers about such options, by initiating option negotiation. An exterior router that has similar capabilities indicates that it accepts the options, completing option negotiation. An exterior router that lacks such options ignores the information in the data field. Open Response Packet When an exterior router receives an Open-Req, it becomes the data sender and responds with an Open Response packet, or Open-Rsp, as follows: If the exterior router accepts the connection, it returns information about its setup in the Open-Rsp. An Open-Rsp also contains an optional data field. This data field indicates whether the exterior router accepts the options in the data field of the Open-Req to which it is responding. If the exterior router cannot accept the connection-for example, because the Open-Req does not contain the correct version number-it returns an error in the Open-Rsp and closes the transport-layer connection. Figure 3-6 shows a connection-opening dialog between a data sender and a data receiver. <<Figure 3-6 Connection-opening dialog>> Oppenheimer [Page 23] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Routing Information Request Packet Under AURP, once two exterior routers establish a connection, the data receiver can request the data sender to send its routing information by sending it a Routing Information Request packet, or RI-Req. Routing Information Response Packets When the data sender receives an RI-Req, it reliably sends a sequence of Routing Information Response packets, or RI-Rsp, to the exterior router requesting the information. The RI-Rsp packets provide a list of exported networks on the data sender's local internet and the distance of each network from the data sender. The data sender must finish sending RI-Rsp packets to the exterior router requesting routing information before it can send any other sequenced data over the connection. Figure 3-7 shows a routing-information request/response dialog between a data sender and a data receiver. <<Figure 3-7 Routing-information request/response dialog>> Zone Information Request Packet The data receiver can obtain zone information for known networks on the data sender's local internet at any time, by sending it a Zone Information Request packet, or ZI-Req. A ZI-Req lists the numbers of networks for which the data receiver is requesting zone information. IMPORTANT: To prevent other exterior routers on a tunnel from sending endless streams of ZI-Req packets across the tunnel-causing what is referred to as a ZIP storm-an exterior router must not export information about a network until it has a complete zone list for that network. Zone Information Response Packets When the data sender receives a ZI-Req, it responds by sending unsequenced Zone Information Response packets, or ZI-Rsp, to the data receiver. Zone information is transaction data-thus, its reliable delivery is not guaranteed. Figure 3-8 shows a zone-information request/response dialog between a data sender and a data receiver. <<Figure 3-8 Zone-information request/response dialog>> Oppenheimer [Page 24] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Recovering Lost Zone Information A data receiver enters a network-to-zone list association in its routing table for each network for which it receives a ZI-Rsp packet. If a data receiver that requested zone information for a network does not receive a complete zone list for that network, it must retransmit ZI-Req packets, requesting zone information for that network, until it receives that network's complete zone information. To determine if any ZI-Rsp packets were lost, the data receiver periodically scans its routing table for networks for which the associated zone lists are incomplete-that is, for zone lists that do not include all zones associated with the networks. The data receiver sends a ZI-Req to each data sender from which it received incomplete zone information, listing the numbers of networks for which it has incomplete zone lists. The data sender responds to zone information requests by sending ZI-Rsp packets containing the requested information to the data receiver. Using AURP-Tr for Initial Information Exchange The following sections describe the use of AURP-Tr-the default transport-layer service for AURP-for initial information exchange. OPEN REQUEST PACKET: An exterior router sends an Open-Req packet to request that an AURP-Tr one-way connection with another exterior router be established specify the connection ID for that connection pass the AURP version number, SUI flags, and optional data to the other exterior router If the exterior router does not receive an Open-Rsp from the exterior router to which it sent an Open-Req, it must retransmit the Open-Req. OPEN RESPONSE PACKET: When using AURP-Tr, an exterior router sends an Open-Rsp to acknowledge that a one-way connection has been established reject a connection return information about its environment, as well as any optional data, to the exterior router from which it received an Open-Req Oppenheimer [Page 25] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 If an exterior router receives an Open-Req on a one-way connection that is already open-that is, if it receives an Open-Req with the same connection ID as an open one-way connection-an Open-Rsp sent previously may have been lost. The exterior router receiving the duplicate Open-Req should send a duplicate Open-Rsp to the sending exterior router, unless it has already received some other packet on the connection-such as an RI-Req-indicating the existence of a fully established connection. ROUTING INFORMATION RESPONSE PACKETS: When responding to a request for routing information using AURP-Tr, an exterior router sends a sequence of RI-Rsp packets to the exterior router requesting the information. However, an exterior router's complete list of network numbers often fits in a single RI-Rsp packet. Each RI-Rsp packet contains the following information: Connection ID: The connection ID identifies the specific one-way connection to which a packet belongs. Sequence number: The sequence number identifies an individual packet on a connection. Packets on a connection are numbered starting with the number 1. The data sender sending routing information must wait for the data receiver to acknowledge that it has received each RI-Rsp packet in the sequence-by sending an RI-Ack packet-before sending the next RI- Rsp packet. Each RI-Rsp contains a flag that indicates whether it is the last packet in the sequence. In the last RI-Rsp in the sequence, this flag is set to 1. If the data sender receives no acknowledgment of an RI-Rsp from the data receiver within a specified period of time, it must retransmit the RI-Rsp. ROUTING INFORMATION RESPONSE PACKETS: When an exterior router receives an RI-Rsp, it verifies the packet's connection ID and sequence number. The connection ID must be the same as that in the Open-Req. The sequence number must be either the last sequence number received, indicating that the previous acknowledgment was lost or delayed, and that this is a duplicate RI-Rsp the next number in the sequence, indicating that this RI-Rsp contains new routing information If the connection ID or sequence number is invalid, the data receiver discards the packet. Figure 3-9 shows a dialog between a data sender and a data receiver in which the data receiver requests routing information, the data sender responds by sending its routing information, and the data receiver acknowledges the data sender's response. If the data sender receives no acknowledgment, it sends Oppenheimer [Page 26] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 duplicate RI-Rsp packets until the data receiver responds with an acknowledgment. <<Figure 3-9 Routing-information request/response/acknowledgment dialog>> Once the data receiver has verified the information in the RI-Rsp, it responds with a Routing Information Acknowledgment packet, or RI-Ack, which contains the following information: Connection ID: The connection ID is the same as that in the RI-Rsp packet. Sequence number: The sequence number is the same as that in the RI- Rsp packet. Send zone information flag: The state of the send zone information (SZI) flag in an RI-Ack packet indicates whether the RI-Ack packet doubles as a ZI-Req packet. If the SZI flag is set to 1, the data receiver sends the zone information associated with the networks about which it sent routing information in the previous RI-Rsp. Figure 3-10 shows a data receiver sending zone information to a data sender in response to a ZI-Req and in response to an RI-Ack, which optimizes the data flow. When the data sender receives an RI-Ack, it verifies that the RI-Ack corresponds to the outstanding RI-Rsp-that is, both packets have the same connection ID and sequence number. Once the data sender has verified the information in the RI-Ack, it responds by sending the next RI-Rsp in the sequence, if any. <<Figure 3-10 Nonoptimized and optimized flows of zone information>> ZONE INFORMATION RESPONSE PACKETS: If the data sender receives an RI-Ack with its SZI flag set to 1, it responds by sending ZI-Rsp packets that contain the zone information associated with the networks about which it sent routing information in the RI-Rsp being acknowledged-just as it would if it received a ZI-Req for those networks. The data sender sends RI-Rsp and ZI-Rsp packets as independent data streams. It sends RI-Rsp packets as sequenced data and ZI-Rsp packets as transaction data. If the data sender receives an RI-Ack with its SZI flag set to 1, it sends an unsequenced series of ZI-Rsp packets that contain the following information: Connection ID: The connection ID is the same as that in the Oppenheimer [Page 27] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 associated RI-Req. Network number and zone list tuples: The exterior router sends the zone information associated with each network number in the corresponding RI-Rsp. Reobtaining Routing Information An exterior router can reobtain another exterior router's complete routing information at any time, by sending an RI-Req packet. An exterior router might need to reobtain complete routing information for a one-way connection on which it is the data receiver under the following circumstances: During the initial routing-information exchange, the exterior router set the SUI flags in the Open-Req to disable updates. The exterior router can subsequently poll the other exterior router on the connection by sending an RI-Req to that exterior router to determine whether any of its routing information has changed. The exterior router set the SUI flags to request updates, but suspects that the routing information for the other exterior router on the connection is incorrect or obsolete. The exterior router should send an RI-Req to the other exterior router to obtain its complete, updated routing information. Whenever an exterior router receives an RI-Req from an exterior router requesting updated routing information, it responds by sending RI-Rsp packets, just as it does when it first receives an RI-Req. The data sender also resets the SUI flags for that one-way connection, so they correspond to those in the RI-Req. If the data sender is sending other sequenced update information when it receives an RI-Req, it cannot respond to the RI-Req until the data receiver acknowledges the last outstanding packet in the sequence. If AURP uses an underlying transport-layer service that does not provide reliable delivery, such as AURP-Tr, it may be necessary for the data receiver to retransmit an RI-Req. Updating Routing Information Once an exterior router receives the routing and zone information for another exterior router's local internet, if the receiving exterior router has set the SUI flags in the Open-Req to request updates, the data sender notifies the data receiver of any subsequent changes to that information. Oppenheimer [Page 28] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Informed-Routers List An exterior router maintains an informed-routers list containing the network address of each exterior router that has requested dynamic updating of routing information. Once an exterior router has sent routing information for its local internet to other exterior routers on the tunnel, it must reliably send updated routing information to all accessible exterior routers in its informed-routers list whenever its routing information changes. Sending Routing Information Update Packets An exterior router communicates changes in its routing information by sending Routing Information Update, or RI-Upd, packets to another exterior router. When the routing information for an exterior router's local internet changes, the exterior router need not send an RI-Upd immediately. Generally, an exterior router buffers the update information, then sends updates periodically. The exterior router must wait at least an update interval between sending updates. The value of this update interval cannot be less than ten seconds should be specifiable by a network administrator It is possible that more than one update event for a particular network might occur within one update interval. One of these events might supercede another-for example, a Network Added event followed by a Network Deleted event for the same network. In this case, the exterior router can represent the two events logically as one event. Under AURP, an exterior router can have only one event pending for a given network. An exterior router can combine any series of events for a network into a single pending event. In Figure 3-11, a state diagram shows the update event that an exterior router should have pending for a network, based on the other events that have occurred during the update interval. <<Figure 3-11 A state diagram showing pending update events>> Four of the states correspond to four pending update events. Two states indicate that no update event is pending: Net Up-indicates that no update event is pending for a network in the exterior router's local internet Net Down-indicates that no update event is pending for a network in another exterior router's local internet or the network does not exist Oppenheimer [Page 29] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 A single RI-Upd packet may contain different types of update events- for example, several Network Added events and several Network Deleted events. For information about update events, see the section "Routing-Information Update Events" later in this chapter. A data sender should send an RI-Upd packet to an exterior router in its informed-routers list only if the packet contains one or more update events of a type indicated by the SUI flags of the last Open- Req or RI-Req received from that exterior router. Because an RI-Upd that contains one or more events of a type requested by an exterior router may also contain events of types not requested, an exterior router must be able to handle events of all types. Thus, a data sender can send an RI-Upd that contains various types of update events to all exterior routers that have requested update events of any of those types. Sending Updates Following the Initial Exchange of Routing Information While a data sender has update events pending-that is, when update events have occurred but the data sender has not yet sent RI-Upd packets for those events-another exterior router may establish a new connection with the data sender. The data sender must present consistent routing information to all exterior routers on the tunnel, on both existing connections and any new connections. For example, if a pending update event indicated that a new network had become available, the newly connected exterior router could be informed of that network's presence on the internet either by sending it an RI-Rsp packet including routing information for the new network sending it an RI-Rsp packet that does not include routing information for the new network, then sending it the RI-Upd packet that includes the pending update event AURP does not specify a scheme for sending update information following the initial exchange of routing information on a new connection. However, the Appendix, "Implementation Details," describes one possible method of doing this. Using AURP-Tr to Update Routing Information The following sections describe the use of AURP-Tr for sending routing-information updates. ROUTING INFORMATION UPDATE PACKETS: Each RI-Upd packet contains the following information: Oppenheimer [Page 30] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Connection ID: The connection ID identifies the specific one-way connection to which the RI-Upd belongs. Sequence number: The sequence number identifies an individual RI-Upd on a connection. If an update cannot be contained in one RI-Upd packet, the data sender must send a sequence of RI-Upd packets. While the data sender need not wait for the duration of an update interval before sending each RI-Upd packet in a sequence, it must wait for the data receiver to acknowledge that it has received the RI-Upd packet that is currently outstanding before sending the next RI-Upd packet in the sequence. If the data sender sending an RI-Upd does not receive an acknowledgment, or RI-Ack, from the data receiver within a specified period of time, the data sender should periodically retransmit the RI-Upd until it receives an acknowledgment from the data receiver. Once the data sender retransmits the RI-Upd a specified number of times, if it does not receive an RI-Ack, it should assume that the one-way connection on which it is the data sender is down. For more information about routers going down, see the section "Using AURP-Tr to Detect Routers Going Down" later in this chapter. ROUTING INFORMATION ACKNOWLEDGMENT PACKET: When a data receiver receives an RI-Upd, it verifies the packet's connection ID and sequence number. The connection ID must be the same as that in the Open-Req for the connection. The sequence number must be either: the last sequence number received, indicating that the previous acknowledgment was lost or delayed, and that this is a duplicate RI-Upd the next number in the sequence, indicating that the RI-Upd contains new routing information If the sequence number has any other value, the data receiver ignores the RI-Upd. Once the data receiver has verified the RI-Upd packet's connection ID and sequence number, it responds by sending a Routing Information Acknowledgment packet, or RI-Ack, which contains the following information: Connection ID: The connection ID is the same as that in the RI-Upd packet. Sequence number: The sequence number is the same as that in the RI- Upd packet. Oppenheimer [Page 31] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Figure 3-12 shows a data receiver responding to an RI-Upd by sending an RI-Ack. <<Figure 3-12 A routing-information update/acknowledgment dialog>> When a data sender receives an RI-Ack, it verifies that the RI-Ack corresponds to the outstanding RI-Upd-that is, both packets have the same connection ID and sequence number. Once the data sender has verified the information in the RI-Ack, it responds by sending the next RI-Upd in the sequence, if any. Routing-Information Update Events An RI-Upd packet may contain any of five different types of routing- information update events. The following sections describe these events. NETWORK ADDED EVENT: An exterior router sends a Network Added (NA) event under the following circumstances: A new network that appears in the exterior router's routing table is in the exterior router's local internet and is not hidden-that is, it is an exported network. The port through which an exterior router accesses a network changes from a tunneling port to another port on the router and the network is not hidden. If a network in an exterior router's routing table becomes accessible across the tunnel, the exterior router does not send an NA event. An exterior router sends only split-horizoned routing information to other exterior routers on the tunnel. An NA event lists the network numbers associated with the new network and the network's distance in hops. Another exterior router can request the zone information associated with the new network at any time by sending a ZI-Req, once it receives an RI-Upd containing an NA event for the network. When using AURP-Tr, an exterior router can request zone information for new networks by setting the SZI bit in an RI-Ack that it sends in response to an RI-Upd. If a data sender receives an RI-Ack with its SZI flag set to 1, the data sender sends the zone information associated with each new network for which it sent an NA event in the RI-Upd. Figure 3-13 shows a data receiver responding to an RI-Upd by sending an RI-Ack in which the SZI bit is set to 1, optimizing the flow of Oppenheimer [Page 32] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 zone information by causing the data sender to respond with a ZI-Rsp. <<Figure 3-13 An optimized flow of zone information>> NETWORK DELETED EVENT: An exterior router sends a Network Deleted (ND) event if an exported network that was formerly accessible through its local internet no longer appears in its routing table. An ND event lists the network numbers associated with the deleted network. NETWORK ROUTE CHANGE EVENT: An exterior router sends a Network Route Change (NRC) event if the path to an exported network through its local internet changes to a path through a tunneling port, causing split-horizoned processing to eliminate that network's routing information. An NRC event lists the network numbers associated with the network to which the path changed. NETWORK DISTANCE CHANGE EVENT: An exterior router sends a Network Distance Change (NDC) event if the distance to an exported network accessible through its local internet changes. An NDC event indicates the network to which the distance changed and the network's distance in hops. An exterior router must send an NDC event even if the distance to a network changes to 15 hops. The exterior router that receives an NDC event with a hop count of 15 should process that event just as it would an ND event. ZONE NAME CHANGE EVENT: This event is reserved for future use. Processing Update Events According to the architectural model, a data receiver that is processing an event contained in an RI-Upd packet updates the corresponding information in its central routing table. For example, if a data receiver receives an RI-Upd containing an ND event or an NRC event, it sets the corresponding network's routing-table entry to BAD. The data receiver then initiates a notify-neighbor process, by sending RTMP data packets that identify bad entries in its routing table to routers on its local internet. Processing Inconsistent Update Events If the data receiver's copy of the data sender's routing table does not match that in the data sender's current routing table, it is possible that the data receiver might receive an RI-Upd containing an event that is incongruous with its current routing-table information. For example, this might occur if the information in the data sender's routing table were changing during its initial exchange of routing information with the data receiver, as described in the section Oppenheimer [Page 33] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 "Sending Updates Following the Initial Exchange of Routing Information" earlier in this chapter. The data receiver might receive an RI-Upd that contains an ND, NRC, or NDC event for a network not known to be in the data sender's routing table; or an NA event for a network already known to be in its routing table. The data receiver should ignore ND and NRC events for unknown networks process an NDC event for an unknown network as an NA event process an NA event for a known network as an NDC event Maintaining a Central Routing Table According to the architectural model, an exterior router maintains a separate routing table for each other exterior router on a tunnel. In a typical implementation, however, an exterior router maintains a central routing table that contains information about each path to each network known to that exterior router-including its port, next internet router (IR), and distance in hops. If no loops exist across a tunnel, an exterior router can reach a network that is accessible through that tunnel through only one exterior router, as shown in Figure 3-14. Such a network is accessible neither through the exterior router's local internet nor through any other exterior router on the tunnel. Thus, the central routing table would contain only one path for that network. If a loop exists across a tunnel, an exterior router may be able to access a network through two or more exterior routers on the tunnel, or through both its local internet and an exterior router. Thus, when a loop exists across a tunnel, the central routing table may contain more than one path for each network. Figure 3-14 shows two examples of internets on which loops exist. <<Figure 3-14 Internets with and without loops>> Maintaining an Alternative-Paths List If a loop exists across a tunnel and an exterior router maintains a single central routing table, that table must include an alternative-paths list for each network known to the exterior router. This alternative-paths list contains the routing information that an exterior router might otherwise maintain in separate routing tables for the other exterior routers on a tunnel. An entry for each alternative path to a network consists of the address of the alternative next IR for that network and the network's distance Oppenheimer [Page 34] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 through that next IR. Because RTMP periodically retransmits information about alternative paths, the exterior router's alternative-paths list needs to provide information only about alternative paths to networks across tunneling ports. Thus, the alternative-paths list for a network provides complete information about all paths to that network across tunnels- but not necessarily about all paths through the exterior router's local internet. An exterior router must maintain an alternative-paths list, because once a data sender has reliably sent routing information to a data receiver, the data sender does not retransmit that information. Even though a path may not currently be the optimal path to a network, an exterior router must maintain information about that path, in the event that it later becomes the optimal path. NOTE: Zone information is unaffected by the path taken to a network. Therefore, an exterior router need not maintain duplicate zone information in the alternative-paths list. Using the Alternative-Paths List in Event Processing An exterior router uses its alternative-paths list when processing events. PROCESSING A NETWORK ADDED EVENT: If an exterior router receives an NA event, it searches its central routing table for the network indicated in the event. If the exterior router finds no entry for that network in its central routing table, it creates a new entry using the routing information contained in the NA event. If the exterior router finds an existing entry for that network in its central routing table and the next IR for that entry is not the exterior router that sent the event, it determines whether the NA event provides a better path to that network. If the NA event provides a better path to the network or the state of the routing-table entry for that network is BAD, the exterior router replaces the current entry with the routing information contained in the NA event. In the current entry, if the path to the network is through a tunnel, as indicated by the next IR, the exterior router transfers the current entry to the network's alternative-paths list. If the NA event does not provide a better path to the network, Oppenheimer [Page 35] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 the exterior router adds the routing information contained in the NA event to the alternative-paths list for the network. If the exterior router finds an existing entry for that network, in which the next IR is the exterior router that sent the event, the exterior router should process the NA event just as it would an NDC event. PROCESSING A NETWORK DELETED EVENT: If an exterior router receives an ND event, it searches its central routing table for the network indicated in the event. If the exterior router finds no entry for that network in its central routing table, it ignores the event. See the section "Processing Inconsistent Update Events" earlier in this chapter. If the exterior router that is the data receiver determines that the exterior router that sent the ND event is the next IR for that network and there is an alternative-paths list for the network, the data receiver replaces the network's current routing information with the entry in the network's alternative-paths list that provides the shortest distance to that network and removes that entry from the network's alternative-paths list. If the network's alternative-paths list contains more than one entry providing the distance that constitutes the shortest distance to the network, the data receiver can use any of those entries. If the exterior router that is the data receiver determines that the exterior router that sent the ND event is the next IR for that network and there is no alternative-paths list for the network, the data receiver sets the network's routing-table entry to BAD, then initiates a notify-neighbor process. If the exterior router that is the data receiver determines that the exterior router that sent the ND event is not the next IR for that network, the data receiver searches that network's alternative-paths list for an entry in which the next IR is the data sender and removes that entry from the list. PROCESSING A NETWORK ROUTE CHANGE EVENT: If an exterior router receives an NRC event, it processes that event as an ND event. Generally, an NRC event should not cause an exterior router to set the state of a network's routing-table entry to BAD. An NRC event indicates that the data sender has an alternative path to the network through the tunnel. The data receiver either is already aware of or will soon discover this alternative path. Oppenheimer [Page 36] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 PROCESSING A NETWORK DISTANCE CHANGE EVENT: If an exterior router receives an NDC event with a hop count of 15, it processes that event just as it would an ND event. Otherwise, it searches its central routing table for the network indicated in the event. If the exterior router finds no entry for that network in its central routing table, it processes that event as an NA event. If the exterior router that is the data receiver determines that the exterior router that sent the NDC event is the next IR for the network, the data receiver replaces the distance to that network that is currently in its central routing table with the distance indicated in the NDC event. If the exterior router that is the data receiver determines that the exterior router that sent the NDC event is not the next IR for the network, the data receiver replaces the distance in the corresponding entry in the network's alternative-paths list with the distance indicated in the NDC event creates an entry in the alternative-paths list that contains the routing information in the NDC event, if it finds no entry for that network in the alternative-paths list Finally, regardless of whether the central routing table indicates that the exterior router that sent the NDC event is the network's next IR, the data receiver compares the distances in entries in the network's alternative-paths list to the distance in its central routing table. If an entry in the alternative-paths list contains a shorter path to the network, the exterior router transfers that entry to the central routing table. This ensures that the exterior router's central routing table contains the shortest path to the network. If the data receiver replaces the entry currently in its central routing table with that in the NDC event and the current entry provides a path to the network through a tunnel, the data receiver transfers the current entry to the network's alternative-paths list. If the data receiver transfers an entry in the network's alternative-paths list to its central routing table, it removes that entry from the alternative-paths list. RESPONDING TO EVENTS IN THE LOCAL INTERNET: An exterior router that uses AURP must respond appropriately to events that originate in its local internet. Such events occur when the routing information for a network in the exterior router's local internet changes and another path to that network exists through the tunnel. An exterior router Oppenheimer [Page 37] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 handles such events as follows: If the exterior router replaces the current routing-table entry for a network with routing information provided by an event originating in its local internet-that is, provided by RTMP-and the current path to the network is through a tunnel, the exterior router transfers the current entry to the network's alternative-paths list. If the exterior router sets the state of a routing-table entry to BAD or removes an entry from its central routing table, the exterior router replaces that entry with the entry in the alternative-paths list that provides the shortest distance to the network in the entry being replaced. If the distance to a network in the exterior router's local internet changes, the exterior router compares the distances in entries in the network's alternative-paths list to the distance in its central routing table. If an entry in the alternative-paths list provides a shorter distance to the network, the exterior router transfers that entry to its central routing table. This ensures that the exterior router's central routing table contains the shortest path to the network. Router-Down Notification Prior to going down, or becoming inactive, an exterior router must notify all other exterior routers in its informed-routers list that it is going down. An exterior router does this by using the underlying transport-layer service to close its connection with each exterior router. Sending a Router Down Packet Optionally, an exterior router can send a Router Down packet, or RD packet, to each exterior router before it goes down. An RD packet contains an error code that indicates the exterior router's reason for terminating its connection with each exterior router. Generally, only the exterior router functioning as the data sender on a one-way connection sends RD packets. However, if just a single one-way connection exists between two exterior routers, the exterior router functioning as the data receiver on that connection can send an RD packet. Using AURP-Tr to Notify Other Routers That a Router Is Going Down When using AURP-Tr, an exterior router sends an RD packet to Oppenheimer [Page 38] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 notify another exterior router that it is terminating a connection pass an error code that indicates its reason for terminating the connection As shown in Figure 3-15, once the data receiver verifies the RD packet's connection ID, it acknowledges that it received the RD packet by sending an RI-Ack. Then, the data sender terminates the connection. <<Figure 3-15 Acknowledging an RD packet>> If a Router Goes Down Without Notifying Other Routers If an exterior router crashes or goes down without sending an RD packet, or becomes inaccessible due to a network problem, other exterior routers on the tunnel must be able to discover that the exterior router is down. Generally, the underlying transport-layer service provides a mechanism for informing an exterior router that an exterior router in its informed-routers list has gone down or become inaccessible. If an exterior router determines that another exterior router is down, it must remove that exterior router from its informed-routers list remove that exterior router's routing information from all of its routing tables close any one-way connections with that exterior router If an exterior router rediscovers an exterior router that had previously gone down, it must again exchange initial routing information with that exterior router. Using AURP-Tr to Detect Routers Going Down An exterior router using AURP-Tr associates a last-heard-from timer with each exterior router from which it has received routing information-that is, with each one-way connection on which it is the data receiver. Each time the exterior router receives an RI-Rsp, RI- Upd, or ZI-Rsp over a connection-verifying that its connection with the data sender is still active-it resets the last-heard-from timer for that connection. For each one-way connection on which it is the data receiver, the exterior router has a last-heard-from timeout value. If a Oppenheimer [Page 39] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 connection's last-heard-from timer reaches that timeout value, the data receiver sends a Tickle packet over that connection. If the data sender on the connection is still accessible, it responds with a Tickle-Ack, as shown in Figure 3-16. When the data receiver receives the Tickle-Ack, it resets the last-heard-from timer for that connection. If the data receiver receives no Tickle-Ack-even after retransmitting the Tickle several times-it assumes that the connection is down. <<Figure 3-16 Acknowledging a Tickle packet>> If the exterior router determines that the connection is down and an associated one-way connection exists on which it is the data sender, it should send a null RI-Upd over that connection to determine whether that one-way connection is still active. If the data receiver on the connection is still accessible, it responds with an RI-Ack, as shown in Figure 3-17. If the data sender receives no RI-Ack-even after retransmitting the null RI-Upd several times-it determines that the one-way connection on which it is the data sender is also down. <<Figure 3-17 Acknowledging an RI-Upd packet>> The value of the last-heard-from timeout should be configurable. The minimum last-heard-from timeout should be 30 seconds. If a connection's last-heard-from timeout is greater than two minutes-the tickle-before-data time-and the data receiver has not reset the connection's last-heard-from timer for at least this tickle-before- data time, the data receiver must send a Tickle to the data sender before forwarding an AppleTalk data packet to it. If the data sender on the connection is still accessible, it responds with a Tickle-Ack. When the data receiver receives the Tickle-Ack, it resets the last- heard-from timer for that connection. If the data receiver receives no Tickle-Ack, even after retransmitting the Tickle, it assumes that the data sender is no longer accessible and closes the connection. Obtaining Zone Information AURP supports two commands that allow an exterior router to obtain routing information for zones rather than for networks-the Get Domain Zone List (GDZL) command and the Get Zone Nets (GZN) command. These commands constitute request/response transactions, and are similar to ZI-Req and ZI-Rsp. An exterior router sends these commands unsequenced over a connection. NOTE: Under AURP, the implementation of the Get Domain Zone List command and the Get Zone Nets command in an exterior router is Oppenheimer [Page 40] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 optional. However, an exterior router must at least be able to return an error to a GDZL-Req or a GZN-Req. Get Domain Zone List Command The Get Domain Zone List command, or GDZL, allows an exterior router to obtain a zone list for an internet. As shown in Figure 3-18, GDZL functions similarly to the ZIP GetZoneList command. However, a GDZL- Rsp returns a split-horizoned zone list-that is, it returns only the zones in the exterior router's local internet, rather than the exterior router's entire zone list. A GDZL-Rsp does not return zones in networks that are accessible through the tunnel, unless those zones are also in networks that are accessible through the exterior router's local internet. <<Figure 3-18 Get Domain Zone List request/response dialog>> Get Zone Nets Command The Get Zone Nets command, or GZN, allows an exterior router to obtain a list of the networks in an exterior router's local internet that are associated with a particular zone name. As shown in Figure 3-19, GZN functions similarly to ZI-Req and ZI-Rsp, but a GZN-Req packet contains a single zone name and GZN-Rsp packets contain network tuples that have the same format as the tuples in an RI-Rsp. A GZN-Rsp returns network tuples only for networks that are accessible through the exterior router's local internet. <<Figure 3-19 Get Zone Nets request/response dialog>> Using AURP-Tr to Process Sequence Numbers When an exterior router acting as a data receiver sends an Open-Req to establish a one-way connection, it expects the data sender to respond by sending sequenced data packets, starting with the sequence number 1. The data receiver's response to each packet that it receives depends on the packet's sequence number: Whenever the data receiver receives an RI-Rsp, RI-Upd, or RD packet that has the expected sequence number and connection ID, it sends an RI-Ack packet having that sequence number, then increases the sequence number that it expects by one, until the sequence number reaches 65,535. Sequence numbers wrap around and the sequence number 0 is reserved, so the sequence number 1 follows 65,535. Thus, when comparing sequence numbers, an exterior router interprets the sequence number 65,535 as one less than the sequence number 1. Oppenheimer [Page 41] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 If the data receiver expects sequence number n and receives a packet with the sequence number n-1, that packet was delayed and is a duplicate of another packet already received. The data receiver must retransmit an RI-Ack packet, because the data sender may not have received the RI-Ack packet previously sent-that is, the RI-Ack may have been lost. If the data receiver expects sequence number n and receives a packet with the sequence number n+1, it should discard the packet and terminate the one-way connection on which it is the data receiver. Because AURP-Tr supports only one outstanding transaction at a time, the receipt of such a packet indicates that the connection is out of sync. If the data receiver expects sequence number n and receives a packet with a sequence number other than n-1, n, or n+1, the packet was delayed and is a duplicate of another packet already received. The data receiver need not send an RI-Ack, because the data sender must have received an RI-Ack for that sequence number prior to sending a packet with the sequence number n-1. The data receiver should discard the packet. NOTE: If the sequence numbers have not wrapped around, a sequence number greater than n+1 indicates that the connection is out of sync. Using AURP-Tr to Process Connection IDs If an exterior router acting as either a data receiver or a data sender on a one-way connection receives a packet from an exterior router with which it has a one-way connection, it checks the connection ID in the packet to verify that the packet was sent on that connection. If the packet contains a connection ID that does not match that expected for the connection, the exterior router discards the packet. If a data sender receives an Open-Req from an exterior router with which it already has a connection and the connection ID does not match that for the connection already established, it should not discard the packet without verifying whether the connection is still active. The receipt of such a packet may indicate that the data receiver on the connection has been restarted and has opened a new one-way connection, without first terminating its original connection. The exterior router acting as the data sender should send a null RI-Upd over the connection to determine whether it is still active. If the data sender receives an RI-Ack in response to the null RI-Upd, it discards the Open-Req and the original connection remains active. If the data sender receives no RI-Ack after retransmitting the null RI-Upd, it closes the original connection, then sends an Oppenheimer [Page 42] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Open-Rsp to the next Open-Req received. NOTE: An exterior router can act as the data sender on only a single one-way connection between itself and a given exterior router. That is, multiple one-way connections in the same direction cannot exist between two exterior routers. When establishing a one-way connection with a given data sender, a data receiver using AURP-Tr must send an Open-Req that has a different connection ID from that used in its last connection with the data sender. Otherwise, if the last connection to the data sender had terminated abnormally and the new connection used the same connection ID, the data sender might determine that the last connection was still active and interpret the Open-Req as a retransmission of the Open-Req for the last connection. The data sender might respond to the Open-Req by sending an Open-Rsp or ignore the Open-Req, but would not open a new connection. If a data receiver's implementation of AURP-Tr cannot guarantee the use of different connection IDs on successive connections with a given data sender, the data receiver must send an RI-Req immediately after it establishes a connection with a data sender. If the data sender already has a connection with the data receiver, it will send an RI-Rsp with a sequence number other than 1. The data receiver should then terminate that connection and open a new connection using a different connection ID. Using Retransmission Timers Under AURP-Tr When an AppleTalk tunnel exists through a foreign network's internet, the delay and loss characteristics of the tunnel's underlying foreign network system complicate the setting of retransmission timers. A physical connection can be built between two exterior routers using different media-for example, a single Ethernet LAN, a fast point-to- point link, an IP internet, or a slow link over an asynchronous modem. It is important to minimize performance degradation due to packets being dropped or delayed by the underlying foreign network system the inefficient use of the underlying foreign network system's resources due to excessive retransmissions Most higher-level transport-layer services provide guaranteed packet delivery. It is not necessary to retransmit AURP packets when using such transport-layer services. When using AURP-Tr, an exterior router should employ an adaptive retransmission algorithm whenever possible. An adaptive retransmission strategy like that used in TCP Oppenheimer [Page 43] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 maintains the estimated times required to send a packet and receive an acknowledgment-that is, average round-trip times maintains standard deviations from the average round-trip times derives retransmission timers from the average round-trip times While AURP does not specify an adaptive retransmission algorithm, the use of such an algorithm is recommended. NOTE: Often, long intervals exist between AURP packets sent successively on a connection by an exterior router-for example, between RI-Upd packets. Therefore, an adaptive retransmission algorithm used with AURP should give more weight to packets sent recently over a connection than would be appropriate for a general data-stream protocol like TCP. When an exterior router initially opens a connection, no transaction history is available. It is recommended that the retransmission algorithm use a truncated, exponential backoff scheme for the initial Open-Req sequence, because the exterior router with which the data receiver is establishing a connection may be inaccessible or down. An exterior router should not retransmit an Open-Req at a rate faster than once every two seconds. Hiding Local Networks From Remote Networks As described in the section "Hiding Local Networks From Tunnels" in Chapter 2, a network administrator can configure an exterior router to hide specific networks in its local internet from networks connected to other exterior routers on the tunnel. When exchanging routing information with other exterior routers on the tunnel, the exterior router exports no routing information for hidden networks in its local internet to exterior routers from which those networks are hidden. An exterior router using AURP does not include routing information for hidden networks in RI-Rsp, RI-Upd, or GZN-Rsp packets sent to exterior routers from which those networks are hidden. The exterior router also excludes from GDZL-Rsp packets any zones that appear only in the zone lists of hidden networks. To maintain network-level security, an exterior router should discard any AppleTalk data packet sent to a network in its local internet by an exterior router from which that network is hidden. NOTE: An exterior router hides a network by excluding the routing information for that network from RI-Rsp, RI-Upd, GZN-Rsp, and GDZL- Rsp packets. However, network management packets-such as RTMP Route Oppenheimer [Page 44] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Data Response (RDR) packets that are not split horizoned, and Simple Network Management Protocol (SNMP) packets-should include the routing information for hidden networks. For detailed information about the effects of AURP on network management, see the section "Network Management" in Chapter 4. AURP Packet Format An exterior router encapsulates both AURP packets and AppleTalk data packets using the same headers. Before forwarding AURP packets across a tunnel, an exterior router encapsulates the AURP packets in packets of the tunnel's underlying foreign network system-by adding the headers required by that network system. For more information about these headers, see the sections "Forwarding Data," "AppleTalk Data- Packet Format," and "AppleTalk Data-Packet Format for IP Tunneling" in Chapter 2. When using AURP-Tr in conjunction with TCP/IP, an exterior router encapsulates AURP packets in UDP packets prior to forwarding them across an IP tunnel through UDP port 387. When another exterior router on the tunnel receives the UDP packets at UDP port 387, it decapsulates the packets. Domain Headers in AURP Packets When forwarding AURP packets across a tunnel, an exterior router adds a domain header immediately preceding each packet. A domain header contains additional addressing information, including its source domain identifier and destination domain identifier (DI). The last two bytes of the domain header are set to 0003, indicating that the packet is an AURP packet rather than an AppleTalk packet. AURP data follows the domain header. Figure 3-20 shows the protocol headers, the domain header, and the routing data header that encapsulate a routing data packet sent across an IP tunnel. <<Figure 3-20 A routing data packet on an IP tunnel>> An exterior router interprets the domain identifiers in the domain header of an AURP packet differently from those in the domain headers of an AppleTalk data packet. Only network entities with AppleTalk addresses have domain identifiers associated with them. Exterior routers do not have AppleTalk addresses on the tunnel-thus, they do not have true domain identifiers. DESTINATION DOMAIN IDENTIFIER: The destination DI in an AURP packet's domain header is the DI that is associated with any network numbers corresponding to networks that reside in the receiving exterior router's domain. Only ZI-Req packets include such network numbers. Oppenheimer [Page 45] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Whenever possible, a domain header should specify a destination DI- that is, the DI for the networks that reside in the domain of the exterior router that is to receive the packet. When an exterior router sends an Open-Req to open a connection, the destination DI is not yet known. However, under the current version of AURP, the exterior router can either derive the destination DI from the destination's IP address or, on point-to-point links, include the null DI. SOURCE DOMAIN IDENTIFIER: The source DI in an AURP packet's domain header is the DI that is associated with any network numbers corresponding to networks that reside in the sending exterior router's domain. RI-Rsp, RI-Upd, ZI-Rsp, and GZN-Rsp packets include such network numbers. A domain header should always specify a source DI-that is, the DI for the networks that reside in the domain of the exterior router that is sending the packet. Routing Data Headers in AURP Packets The routing data header that immediately precedes the AURP data in a routing data packet consists of an AURP-Tr header and an AURP header. The AURP-Tr header consists of the following fields: Connection ID: The contents of this two-byte field identify the specific one-way connection to which a packet belongs. Sequence number: The contents of this two-byte field identify an individual packet on a connection. The AURP header consists of these fields: Command code: This two-byte field identifies the command type. For information about command types, see the next section, "Command Types." Flags: This two-byte field may contain different flags, depending on the command code. For information about flags, see the section "Routing Flags" later in this chapter. Command Types AURP defines the command types shown in Table 3-1: Oppenheimer [Page 46] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Table 3-1 Command types Command Command type Abbreviation code Subcode Routing Information Request RI-Req 1 - Routing Information Response RI-Rsp 2 - Routing Information Acknowledgment RI-Ack 3 - Routing Information Update RI-Upd 4 - Router Dow RD 5 - Zone Information Request ZI-Req 6 1 Zone Information Response ZI-Rsp 7 1 and 2 Get Zones Net Request GZN-Req 6 3 Get Zones Net Response GZN-Rsp 7 3 Get Domain Zone List Request GDZL-Req 6 4 Get Domain Zone List Response GDZL-Rsp 7 4 Open Request Open-Req 8 - Open Response Open-Rsp 9 - Tickle - 14 - Tickle Acknowledgment Tickle-Ack 15 - Routing Flags AURP defines the flags shown in Table 3-2. All other flags are reserved. A data sender should set reserved flags to 0. A data receiver should ignore reserved flags. Table 3-2 Flags Flag Event Command types Bit Send update information (SUI) flag NA Open-Req and RI-Req 14 Send update information (SUI) flag ND and NRC Open-Req and RI-Req 13 Send update information (SUI) flag NDC Open-Req and RI-Req 12 Send update information (SUI) flag ZC Open-Req and RI-Req 11 Last flag - RI-Rsp and GDZL-Rsp 15 Remapping active flag - Open-Rsp 14 Hop-count reduction active flag - Open-Rsp 13 Reserved environment flags - - 12 and 11 Send zone information (SZI) flag - RI-Ack 14 Figure 3-21 shows the routing flags in Open-Req and RI-Req packets. <<Figure 3-21 Routing flags in Open-Req and RI-Req packets>> Figure 3-22 shows the routing flags in all packets other than Open- Req and RI-Req packets. Oppenheimer [Page 47] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 <<Figure 3-22 Routing flags in other packets>> Open Request Packet An Open-Req packet initiates the establishment of a one-way connection with a data sender. Figure 3-23 shows the format of an Open-Req packet. When sending an Open-Req packet, an exterior router inserts the next available connection ID in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of an Open-Req contains the command code 8. Its flag bytes contain send update information (SUI) flags. For the current version of AURP, the version number is 1. An Open-Req packet's option data field contains an option count-indicating the number of option tuples to follow the option tuples When the data sender receives an Open-Req, it can discard the option tuples for any options it does not implement. For information about option tuples, see the section "Option Tuples" later in this chapter. <<Figure 3-23 Open-Req packet format>> Open Response Packet When the data sender receives an Open-Req, it responds by sending an Open-Rsp packet to establish a one-way connection with the data receiver. Figure 3-24 shows the format of an Open-Rsp packet. In its AURP-Tr header, an Open-Rsp packet contains the connection ID from the associated Open-Req packet and the sequence number 0. The AURP header of an Open-Rsp contains the command code 9 and its flag bytes contain environment flags that provide information about the data sender's environment-such as whether network-number remapping or hop-count reduction is active. For information about network-number remapping and hop-count reduction, see the sections "Network-Number Remapping" and "Hop-Count Reduction," respectively, in Chapter 4. <<Figure 3-24 Open-Rsp packet format>> An Open-Rsp packet's option data field contains a two-byte field that indicates either the nominal rate at which the data sender sends updates-in multiples of ten seconds an error code-which is a negative number-if the data sender cannot accept the connection Oppenheimer [Page 48] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 an option count-indicating the number of option tuples to follow the option tuples For information about error codes, see the section "Error Codes" later in this chapter. For information about option tuples, see the next section, "Option Tuples." Option Tuples Both Open-Req and Open-Rsp packets contain option tuples. An option tuple contains a one-byte length field that indicates the length of the remainder of the tuple, a one-byte type code, and an optional data field, as shown in Figure 3-25. <<Figure 3-25 Option tuples>> AURP currently defines the option-type codes shown in Table 3-3: Table 3-3 Option-type codes Option types Type codes Authentication 1 Reserved for future use 2-255 Routing Information Request Packet An RI-Req packet requests the data sender to send RI-Rsp packets. Figure 3-26 shows the format for an RI-Req packet. When sending an RI-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets the packet's sequence number to 0. The AURP header of an RI-Req contains the command code 1 and its flag bytes contain the send update information (SUI) flags. <<Figure 3-26 RI-Req packet format>> Routing Information Response Packet When the data sender receives an RI-Req, it responds by sending a sequence of RI-Rsp packets. Figure 3-27 shows the format of an RI-Rsp packet. When sending an RI-Rsp packet, a data sender inserts the connection ID from the associated RI-Req in the RI-Rsp packet's AURP-Tr header and sets its sequence number to the next number in the sequence. The AURP header of an RI-Rsp packet contains the command code 2. In the last packet in a sequence of RI-Rsp packets, the Oppenheimer [Page 49] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 last-flag bit is set to 1. <<Figure 3-27 RI-Rsp packet format>> An RI-Rsp packet's routing data field contains zero or more routing tuples, which have a format similar to those in RTMP packets. An AURP tuple for a nonextended network is different from an RTMP tuple for an extended network in one respect-the range flag, or the sixth byte, in an AURP tuple for a nonextended network is set to 0. Figure 3-28 shows nonextended and extended network tuples in an RI-Rsp packet. <<Figure 3-28 Nonextended and extended network tuples>> Routing Information Acknowledgment Packet When a data receiver receives an RI-Rsp, RI-Upd, or RD packet, it responds by sending an RI-Ack packet. Figure 3-29 shows the format of an RI-Ack packet. When sending an RI-Ack packet, a data receiver inserts the connection ID and sequence number from the associated RI-Rsp, RI-Upd, or RD packet in the RI-Ack packet's AURP-Tr header. The AURP header of an RI-Ack contains the command code 3. If the data receiver sends an RI-Ack using AURP-Tr, in response to an RI-Rsp or RI-Upd packet that contains an NA event, its flag bytes contain the send zone information flag. An RI-Ack packet contains no data. <<Figure 3-29 RI-Ack packet format>> Routing Information Update Packet The occurrence of specified events requires the data sender to send an RI-Upd packet. Figure 3-30 shows the format of an RI-Upd packet. When sending an RI-Upd packet, a data sender inserts the connection ID for the current connection in the RI-Upd packet's AURP-Tr header and sets its sequence number to the next number in the sequence. The AURP header of an RI-Upd contains the command code 4 and its flag bytes are set to 0. <<Figure 3-30 RI-Upd packet format>> An RI-Upd packet's data field contains one or more event tuples. An event tuple for a nonextended network consists of a one-byte event code, the network number, and the distance to that network. An event tuple for an extended network consists of a one-byte event code, the first network number in the range of network numbers, the distance to the network, and the last network number in the range of network numbers. Figure 3-31 shows nonextended and extended network tuples in an RI-Upd packet. Oppenheimer [Page 50] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 <<Figure 3-31 Nonextended and extended network event tuples>> AURP currently defines the event codes shown in Table 3-4: Table 3-4 Event codes Event Abbreviation Event code Null event 0 Network Added event NA 1 Network Deleted event ND 2 Network Route Change event NRC 3 Network Distance Change event NDC 4 Zone Change event ZC 5 A null event tuple contains no event data. The format of NA, ND, NRC, and NDC event tuples differs, depending on whether the event pertains to a nonextended or an extended network. The distance field does not apply to ND or NRC event tuples and should be set to 0. The ZC event tuple is not yet defined. An RI-Upd packet should never contain two events that pertain to the same network. However, to ensure consistent behavior in the event that an exterior router receives a packet containing multiple events for one network, an exterior router should always process events in the order in which they occur in the RI-Upd packet. Thus, if an exterior router were to receive an RI-Upd that contained an NA event, then an ND event for the same network, the exterior router would delete the network from its routing table. Router Down Packet An exterior router should send an RD packet before it goes down. Figure 3-32 shows the format of an RD packet. When sending an RD packet, an exterior router inserts the connection ID for the current connection in the RD packet's AURP-Tr header. If the data sender sends an RD packet, it sets its sequence number to the next number in the sequence. If the data receiver sends an RD packet, it sets its sequence number to 0. The AURP header of an RD packet contains the command code 5 and its flag bytes are set to 0. <<Figure 3-32 RD packet format>> An RD packet's data field contains a two-byte error code that indicates the exterior router's reason for going down. For information about the error codes, see the section "Error Codes" later in this chapter. Oppenheimer [Page 51] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Zone Information Request/Response Transactions An exterior router returns information about its zones through request/response transactions. Three types of zone requests-ZI-Req, GDZL-Req, and GZN-Req-share the same command code and have subcodes that indicate the actual request type. Three types of zone responses-ZI-Rsp, GDZL-Rsp, and GZN-Rsp-share another command code and have subcodes that indicate the actual response type. ZONE INFORMATION REQUEST PACKET: A ZI-Req packet causes the data sender to send ZI-Rsp packets. Figure 3-33 shows the format of a ZI- Req packet. When sending a ZI-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets the packet's sequence number to 0. The AURP header of a ZI-Req contains the command code 6 and its flag bytes are set to 0. <<Figure 3-33 ZI-Req packet format>> A ZI-Req packet's data field contains the subcode 1 and a two-byte network number for each network about which the exterior router is requesting zone information. The network number for an extended network is the first network number in its range of network numbers. ZONE INFORMATION RESPONSE PACKET: There are two types of ZI-Rsp packets-nonextended ZI-Rsp packets and extended ZI-Rsp packets. The format of a nonextended ZI-Rsp packet is similar to that of a nonextended AppleTalk ZIP Reply packet. When the data sender receives a ZI-Req and the zone list for the network or networks for which that ZI-Req requested zone information fits in one ZI-Rsp packet, it sends a nonextended ZI-Rsp. An extended ZI-Rsp packet is similar to an extended AppleTalk ZIP Reply packet. When the data sender receives a ZI-Req and the zone list for a network about which that ZI-Req requested zone information does not fit in a single ZI-Rsp packet, it sends a sequence of extended ZI-Rsp packets. Figure 3-34 shows the format of a ZI-Rsp packet. When sending a ZI- Rsp packet, a data sender inserts the connection ID from the associated ZI-Req packet in the packet's AURP-Tr header and sets the packet's sequence number to 0. A ZI-Rsp packet's AURP header contains the command code 7 and its flag bytes are set to 0. The subcode 1 indicates a nonextended ZI-Rsp packet, while the subcode 2 indicates an extended ZI-Rsp packet. <<Figure 3-34 ZI-Rsp packet format>> Oppenheimer [Page 52] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 A ZI-Rsp packet's data field contains the requested zone information. Its format is similar to that of a ZIP Reply packet. In a nonextended ZI-Rsp packet, the first two bytes of the data field should indicate the number of tuples contained in the packet, while the remaining bytes constitute network number/zone name tuples. Within the packet, all of the tuples for a given network must be contiguous. NOTE: When sending a nonextended ZI-Rsp packet, an exterior router should attempt to specify the correct number of zone tuples. However, an exterior router receiving a nonextended ZI-Rsp packet should process all tuples contained in the packet, regardless of the number indicated in the header. Network number/zone name tuples in a nonextended ZI-Rsp packet can use either the long tuple format or the optimized tuple format. A long network number/zone name tuple contains a network number, followed by the length of the zone name, and the zone name. Using the optimized tuple format, an exterior router can compress a nonextended ZI-Rsp packet in which more than one network contains the same zone name in its zone list. If the high-order bit of the length byte for a given zone name is set to 1, the following 15 bits represent an offset from the length byte of the first zone name in the packet's data field to the actual location of the zone name length and the zone name. Whenever possible, it is recommended that an exterior router send optimized ZI-Rsp packets. All exterior routers must be able to receive optimized ZI-Rsp packets. In an extended ZI-Rsp packet, the first two bytes of the data field indicate the total number of tuples in the zone list for the network or networks for which the corresponding ZI-Req requested zone information. The remaining bytes in the data field of an extended ZI-Rsp packet consist of network number/zone name tuples. All tuples in a single extended ZI-Rsp packet must contain the same network number. However, for consistency with the format of network number/zone name tuples in nonextended ZI-Rsp packets, the network number precedes each zone name in an extended ZI-Rsp packet. Duplicate zone names never exist in extended ZI-Rsp packets- therefore, extended ZI-Rsp packets use the long tuple format, rather than the optimized tuple format. Figure 3-35 shows the long tuple and optimized tuple formats for a ZI-Rsp packet. <<Figure 3-35 Long and optimized tuple formats>> GET DOMAIN ZONE LIST REQUEST PACKET: A Get Domain Zone List Request packet, or GDZL-Req, requests the data sender to send GDZL-Rsp Oppenheimer [Page 53] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 packets. Figure 3-36 shows the format for a GDZL-Req packet. When sending a GDZL-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GDZL-Req contains the command code 6 and its flag bytes are set to 0. <<Figure 3-36 GDZL-Req packet format>> A GDZL-Req packet's data field contains the subcode 4 and the start index in the data sender's zone list at which to begin returning GDZL-Rsp packets. GET DOMAIN ZONE LIST RESPONSE PACKET: When the data sender receives a GDZL-Req, it responds by sending a GDZL-Rsp packet. Figure 3-37 shows the format of a GDZL-Rsp packet. When sending a GDZL-Rsp packet, a data sender inserts the connection ID from the associated GDZL-Req packet in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GDZL-Rsp contains the command code 7 and its flag bytes are set to 0, except in the last packet containing zone information, which has its last flag set to 1. <<Figure 3-37 GDZL-Rsp packet format>> A GDZL-Rsp packet's data field contains the subcode 4, the start index from the associated GDZL-Req, and the zone list. If the data sender does not support the GDZL-Req, it should set the start index to -1. GET ZONES NET REQUEST PACKET: A Get Zones Net Request packet, or GZN-Req, requests the data sender to send zone information for one specific zone. Figure 3-38 shows the format of a GZN-Req packet. When sending a GZN-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GZN-Req contains the command code 6 and its flag bytes are set to 0. <<Figure 3-38 GZN-Req packet format>> A GZN-Req packet's data field contains the subcode 3 and the name of the zone about which the GZN-Req is requesting zone information. GET ZONES NET RESPONSE PACKET: When the data sender receives a GZN- Req, it responds by sending a GZN-Rsp packet, containing the requested zone information. Figure 3-39 shows the format of a GZN-Rsp packet. When sending a GZN-Rsp packet, a data sender inserts the connection ID from the associated GZN-Req packet in the GZN-Rsp Oppenheimer [Page 54] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 packet's AURP-Tr header and sets the GZN-Rsp packet's sequence number to 0. The AURP header of a GZN-Rsp contains the command code 7 and its flag bytes are set to 0. <<Figure 3-39 GZN-Rsp packet format>> A GZN-Rsp packet's data field contains the subcode 3, the zone name from the associated GZN-Req, the total number of network tuples for that zone, and as many network tuples as can fit in the packet. These tuples have the same format as those in RI-Rsp packets. If the data sender has no information about the zone, it returns a GZN-Rsp in which the number of network tuples is 0. If the data sender does not support the GZN-Req, it should set the number of network tuples to -1. TICKLE PACKET: The data receiver sends a Tickle packet to verify that the data received from the data sender is still valid. Figure 3-40 shows the format of a Tickle packet. When sending a Tickle packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a Tickle contains the command code 14 and its flag bytes are set to 0. A Tickle packet contains no data. <<Figure 3-40 Tickle packet format>> TICKLE ACKNOWLEDGMENT PACKET: When the data sender receives a Tickle, it responds by sending a Tickle-Ack packet. Figure 3-41 shows the format of a Tickle-Ack. When sending a Tickle-Ack, a data sender inserts the connection ID from the associated Tickle in the Tickle- Ack packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a Tickle-Ack packet contains the command code 15 and its flag bytes are set to 0. A Tickle-Ack packet contains no data. <<Figure 3-41 Tickle-Ack packet format>> Error Codes Open-Rsp and RD packets contain error codes. AURP currently defines the error codes listed in Table 3-5. Table 3-5 Error codes Error code Error -1 Normal connection close -2 Routing loop detected -3 Connection out of sync Oppenheimer [Page 55] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 -4 Option-negotiation error -5 Invalid version number -6 Insufficient resources for connection -7 Authentication error 4. REPRESENTING WIDE AREA NETWORK INFORMATION This chapter describes optional features of AURP-some of which can also be implemented on routers that use RTMP rather than AURP for routing-information propagation. It provides detailed information about the presentation of wide area network information by exterior routers to nodes on their local internets or to other exterior routers, including: basic security-both network hiding and device hiding remapping of remote network numbers internet clustering loop detection hop-count reduction hop-count weighting backup paths network management Network Hiding An exterior router can hide networks by importing or exporting routing information only about specific networks. Importing Routing Information About Specific Networks A network administrator can configure a tunneling port on an exterior router to import only a subset of the routing information that it receives through the tunnel. To do so, the administrator hides specific networks connected to other exterior routers on the tunnel from the exterior router's local internet. For example, an exterior router can import only that routing information received from specific exterior routers, or routing information for networks in a specific network range or zone. By importing routing information only about specific networks, an exterior router can greatly reduce Oppenheimer [Page 56] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 the amount of routing information maintained by routers on its local internet the number of zones and devices that are visible to devices on its local internet Exporting Routing Information About Specific Networks A network administrator can configure a tunneling port on an exterior router to export only a subset of its local internet's routing information-by hiding from other exterior routers on the tunnel specific networks in its local internet. For more information about hiding networks from other exterior routers, see the section "Hiding Local Networks From Tunnels" in Chapter 2. Device Hiding A router can prevent a device in its local internet from being visible to other nodes on a specific part or all other parts of the internet by not forwarding Name Binding Protocol (NBP) LkUp-Reply packets from that device. Hiding a device prevents nodes on the part of the internet from which it is hidden from knowing the name of the hidden device, making it more difficult for those nodes to access the hidden device. Any AppleTalk Phase 2 router can hide devices. Advantages and Disadvantages Device hiding is a flexible security mechanism that is appropriate for organizations that do not require true device-specific security. It is not a substitute for device-specific security. Device hiding can provide a degree of security on devices for which no other form of security exists-such as LaserWriter printers. A user can write a program that can obtain access to a hidden device using its AppleTalk address. Device hiding cannot secure a device from a user that is not using NBP to access the device. Device hiding does not provide true device-specific security. Many devices require device-specific security-for example, AppleShare file servers. Device-specific security can provide various levels of security, and may allow a network administrator to grant access privileges based on registered users and groups. Configuring Device Hiding on a Port When configuring a port on a router that implements device hiding, a network administrator should be able to hide any device that is accessible through that port from the other ports on the router. The Oppenheimer [Page 57] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 device being hidden need not reside on the network connected directly to the port being configured. An administrator should be able to specify the ports from which to hide a device-either specific ports or all other ports. When hiding devices, an administrator should be able to specify that a list of devices either be hidden or visible. The device list should include device names and device types-for example, We-B- Nets:AFPServer. An administrator should also be able to hide all devices of a given type-for example, all LaserWriter printers-or all devices of all types. Filtering NBP LkUp-Reply Packets To implement device hiding, a router selectively filters NBP LkUp- Reply packets. When a port's configuration specifies that devices accessible through the port be hidden, the router monitors all NBP LkUp-Reply packets received through that port- called the incoming port determines the port through which it is to forward such a packet- called the outgoing port obtains-from the port configuration for the incoming port-the list of devices to be hidden from the outgoing port determines whether it should filter all or part of an NBP LkUp- Reply packet If a port's configuration does not specify that devices be hidden from the outgoing port, the router forwards the packet. If a port's configuration specifies that devices be hidden from the outgoing port, the router checks each tuple in the NBP LkUp- Reply packet to determine whether it is from a device in the port's list of hidden devices. It marks tuples from hidden devices for deletion. Once the router scans the entire packet, it forwards the packet if no tuples were marked for deletion; it discards the packet if all tuples were marked for deletion; or, if only some tuples were marked for deletion, it rebuilds the packet without the tuples marked for deletion, then forwards the packet. When the router rebuilds a packet, it adjusts the tuple count in the packet's NBP header to reflect the number of tuples remaining. If a rebuilt packet's DDP header contains a nonzero checksum, the router Oppenheimer [Page 58] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 verifies the original checksum, then sets it to 0. This device-hiding scheme can handle both NBP Lookups and NBP Confirms, because a node responds to requests of either type with a LkUp-Reply packet. LkUp-Reply packets do not contain the names of zones in which devices reside. Thus, if two devices having the same name and type are accessible through a port, a network administrator can hide both devices or neither device, but not just one of the devices. When configuring ports on routers through which redundant paths to a device exist, a network administrator must hide that device on at least one port on each path to that device. Otherwise, only a router on which such a port was configured to hide the device would filter LkUp-Reply packets from the device. A router on which such a port was not configured to hide the device would not filter its LkUp-Reply packets. Figure 4-1 shows the proper configuration of device hiding when a loop exists on the internet. <<Figure 4-1 Device hiding when a loop exists on the internet>> Resolving Network-Numbering Conflicts In addition to interconnecting different parts of one organization's internet, tunnels can interconnect the internets of multiple organizations. Each organization administrates its internet independently. Therefore, conflicting network numbers may exist on the internets, especially when many internets are interconnected. The following sections describe the methods that AURP uses to resolve various problems due to conflicting network numbers. Network-Number Remapping Network-number remapping resolves network-numbering conflicts, allowing network administrators to build very large internets. When configuring a port on an exterior router, an administrator can specify a range of AppleTalk network numbers to be used for imported networks-that is, networks that are accessible through half-routing or tunneling ports, for which the exterior router imports routing information from other exterior routers. The remapping range-the range of network numbers reserved for network-number remapping-must not conflict with any network numbers already in use on the exterior router's local internet. The exterior router maps the network numbers in incoming packets into the remapping range. It converts remapped network numbers back to their actual network numbers for outgoing packets. To nodes and Oppenheimer [Page 59] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 routers within the exterior router's local internet, packets containing remapped network numbers apparently originate from or are being sent to networks having numbers in the remapping range. UNIQUE IDENTIFIERS: In a tunneling environment, many different internets may include AppleTalk networks that have the same network numbers. Therefore, each exterior router on an internet must associate a unique identifier (UI) with each network that it exports across the tunnel-that is, each network in its local internet that is not hidden. Generally, some type of global administration of UIs is necessary. On a given tunnel, each exterior router on which network-number remapping is active must have a unique domain identifier (DI). An exterior router using AURP derives a network's UI by concatenating the exterior router's DI-which is unique on the tunnel-with the packet's network number or range-which is unique within the exterior router's domain. For more information about domain identifiers, see the section "Domain Identifiers" in Chapter 2. On a tunneling port, an exterior router refers to AppleTalk network numbers and network ranges using UIs. Whenever an exterior router sends or receives AppleTalk data packets across the tunnel, it refers to any network numbers or ranges in the packets-for example, in a packet's DDP header-by their UIs. For example, when an exterior router sends an RI- Rsp, which provides a list of network ranges for its local internet to other exterior routers on the tunnel, it lists the UIs corresponding to those network ranges. When an exterior router receives RI-Rsp packets from other exterior routers on the tunnel, it interprets the data in each packet as a list of UIs. Network-number remapping should be an optional component of any tunneling scheme. An administrator should be able to configure a tunneling port with or without specifying network-number remapping. When network-number remapping is inactive on all of the exterior routers on a tunnel, each AppleTalk network number and range associated with the exterior routers must be unique. MAPPINGS: An exterior router uses the following process to map AppleTalk network numbers and ranges to UIs, and vice versa: The exterior router logically maps network numbers in the exterior router's local internet to the corresponding UIs before sending a packet out the tunneling port, as shown in Figure 4-2. The UI consists of the source DI in the domain header and the network number from the packet. Therefore, the exterior router changes no data in the packet to perform this mapping. Oppenheimer [Page 60] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 The exterior router logically maps UIs corresponding to local networks in packets received through the tunneling port back to their local network numbers before forwarding the packets to the exterior router's local internet, as shown in Figure 4-2. The exterior router changes no data in the packet. This mapping is the inverse of the previous mapping. The exterior router maps UIs corresponding to network numbers for remote networks-that is, networks connected to other exterior routers on the tunnel-that are in packets received through the tunneling port to network numbers in the remapping range configured for the local internet, as shown in Figure 4-2. An exterior router remaps network numbers from the following fields in this way: the source network number field in the DDP header of an AppleTalk data packet the NBP entity address field in an AppleTalk data packet the routing data field in an AURP routing-information packet The exterior router maps network numbers in the remapping range configured for the local internet back to the corresponding UIs before sending packets out the tunneling port, as shown in Figure 4-2. This type of remapping applies only to network numbers that reside in a destination network-number field of a DDP header in an AppleTalk data packet. This mapping is the inverse of the previous mapping. <<Figure 4-2 Mappings between local and remote internets' network numbers and UIs>> NOTE: Network-number remapping changes an AppleTalk data packet's DDP header and may also change its data. Thus, if a packet contains a DDP checksum, when the exterior router remaps network numbers contained in the packet, it must verify that the checksum is correct, then set the checksum to 0. If the checksum is incorrect, the exterior router should discard the packet. An exterior router can perform network-number remapping either statically or dynamically. Static remapping reserves specific network numbers in the remapping range for mapping specific UIs. Dynamic remapping assigns network numbers in the remapping range to networks as they become known to an exterior router. Static remapping is simpler to implement and provides a known mapping for use in network management. However, it may limit the number of UIs that an exterior router can import into its local internet. Oppenheimer [Page 61] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Dynamic mapping requires a scheme for network number reuse, but may provide connectivity to a greater number of networks across a tunnel. To avoid having the same UI refer to two different networks when remapping network numbers dynamically, an exterior router should reuse network numbers in its remapping range only when no other network numbers are available. If a network goes down, an exterior router should not immediately reassign the UI that referred to that network to another network that just came up on the internet. An exterior router connected to more than one tunnel should function as though it were two exterior routers-each connected to one tunnel and both connected to one AppleTalk internet. Thus, such an exterior router must use remapped network numbers when sending routing information across a tunnel about networks that are accessible through another tunnel. Network Numbers in Data To remap network numbers properly, an exterior router must be aware of their presence within AppleTalk data packets. It is difficult to detect network numbers in data packets, because they could be anywhere within a data packet. For example, NBP includes network addresses as part of its data-in entity addresses. However, the data packets for very few protocols contain any network numbers. Some third-party protocols may contain network addresses in their data. Protocols that contain network addresses in their data may not function properly across remapping exterior routers. Packets used for network management-such as RTMP Route Data Response (RDR) and Simple Network Management Protocol (SNMP) packets-contain network numbers in their data. For detailed information about handling network numbers in SNMP packets, see the section "Network Management" later in this chapter. Problems With Loops Network-number remapping introduces some problems on an internet when loops exist across a tunnel. If network-number remapping is active, two AppleTalk internets connected by a tunnel should not be interconnected in any other way. If a redundant path to an internet exists, a remapped network range can loop back through that path to the exterior router that originally remapped the network range. When this occurs, two different network ranges-the network range actually configured and the remapping of the configured range-refer to one network. Oppenheimer [Page 62] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 The remapped network range apparently refers to a new network in the exterior router's local internet. Such a network is referred to as a shadow network. The exterior router cannot determine that it has received a network range that it had previously remapped, because there is no apparent difference between a remapped network range and an actual network range. Thus, unless an administrator configures an exterior router with an explicit list of networks to export, the exterior router again remaps the network range, then exports the remapped network range, sending it around the loop. The network range is remapped repeatedly until the apparent distance to the network exceeds the hop-count limit. Exterior routers that implement network-number remapping should avoid establishing such infinite loops. For information about preventing such loops, see the section "Routing Loops" later in this chapter. Redundant Paths Under certain circumstances, it might be desirable to create a redundant path, which is a special type of loop. Redundant paths connect an internet to a tunnel through two or more exterior routers. If network-number remapping is active, all redundant exterior routers must use the same DI to represent the local internet-and must map UIs representing remote networks in incoming packets to the same local network numbers. To allow redundant exterior routers to achieve such cooperation, a network administrator might configure all redundant exterior routers with the same DI and complete remapping information for all imported networks. Alternatively, a network administrator might configure one exterior router with this information and all redundant exterior routers could obtain the information from the configured exterior router. AURP does not currently support this functionality, but may do so in the future. Tunnels With Partial Network-Number Remapping When network-number remapping is active on a tunneling port, an exterior router maps network numbers in packets received through the tunnel into the remapping range for its local internet. Because a network administrator configures network-number remapping on individual exterior routers, network-number remapping may be configured on some exterior routers on a tunnel, but not on others- potentially causing network-numbering conflicts due to partial network-number remapping. Whenever possible, an administrator should configure network-number remapping either on all exterior routers on a tunnel or on none of them. Otherwise, network-numbering conflicts are likely to occur on some of the exterior routers-especially on large, interorganizational internets. Oppenheimer [Page 63] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 In addition to potential network-numbering conflicts, partial network-number remapping and the lack of loop detection between nonremapping exterior routers may cause shadow copies of networks connected to more than one nonremapping exterior router to appear in the routing tables on remapping exterior routers. An exterior router on which network-number remapping is active performs loop detection. Therefore, when network-number remapping is active on all of the exterior routers on a tunnel, no loops can exist across the tunnel. However, exterior routers on which network-number remapping is not active do not perform loop detection. Thus, when network-number remapping is not active on some of the exterior routers on a tunnel, any loops that exist between nonremapping exterior routers are not detected. In the example shown in Figure 4-3, shadow copies of all networks that are in the local internets of both exterior router B and exterior router C, on which network-number remapping is not active, appear in the routing table of exterior router A, on which network- number remapping is active. <<Figure 4-3 A tunnel with partial network-number remapping>> Clustering Remapped Networks Because a remapping range is a range of sequential network numbers, an exterior router can represent multiple remapped networks as a single extended network within its local internet-that is, it can cluster remapped networks. Clustering greatly reduces the size of the routing tables that are maintained and sent by routers within an internet, as well as the amount of RTMP traffic on the internet. Clustering may also reduce the amount of NBP traffic on an internet. For example, as shown in Figure 4-4, if networks in an internet have the numbers 1, 100, and 1000, and an exterior router connected to a different part of the internet receives these network numbers across the tunnel, that exterior router might remap the network numbers to 21, 22, and 23. When sending RTMP packets within its local internet, the remapping exterior router can represent the three networks as a single extended network with a network range from 21 to 23. The zones associated with the extended network include all of the zones associated with the three imported network numbers. <<Figure 4-4 Clustering remapped network numbers>> An exterior router determines which remapped network numbers it should cluster. For example, an exterior router might create one cluster for each other exterior router on the tunnel. However, an Oppenheimer [Page 64] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 exterior router can include no more than 255 zones in one cluster. An exterior router that implements clustering must maintain the actual network range and zone list for each network in a cluster. The exterior router monitors all NBP FwdReq packets to be forwarded across the tunnel-including those it generates in response to BrRq packets. It examines the DDP destination network number in each FwdReq packet to determine the cluster to which it is addressed. The exterior router then generates one FwdReq packet for each clustered network for which the FwdReq packet contains a zone name, and sends that packet to the next internet router for the network. The DDP destination network number in such a FwdReq packet corresponds to the starting network number of a network's actual network range. A disadvantage of clustering is that clusters are static. An exterior router cannot notify its local internet that a specific network or zone in a cluster has gone down. An exterior router's implementation of clustering could allow a network administrator to initiate reclustering-in which the exterior router notifies the internet that an entire cluster has gone down, then creates a new cluster that does not include the networks that have gone down. However, such reclustering would cause a temporary loss of connectivity to those networks in the cluster that are still accessible. Therefore, an exterior router should not automatically recluster network numbers. REUSING NETWORK NUMBERS WITHIN A CLUSTER: Under certain conditions, an exterior router that implements clustering might reuse network numbers within a cluster. If a network went down, then came back up with the same zone list, an exterior router could map its network range into the same remapping range and include it in the same cluster. Otherwise, an exterior router should not reuse network numbers within a cluster, unless no other network numbers within the remapping range are available. In any case, an exterior router can reuse network numbers within a cluster only if a new network has a network range that fits in an unused range of network numbers within the cluster and a zone list that is a subset of the cluster's zone list. The implementation of clustering in an exterior router is complex. See the Appendix, "Implementation Details," for some ways in which clustering could be implemented. Zone-Name Management To enhance zone-name management within an AppleTalk internet, AURP provides Get Domain Zone List and Get Zone Nets requests-which function similarly to the ZIP GetZoneList command and ZI-Req command, respectively. However, as when using RTMP and ZIP, if two networks in Oppenheimer [Page 65] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 an internet include zones that have the same zone name in their zone lists, exterior routers merge the zones into one zone-regardless of whether network-number remapping is active on one or more of the exterior routers. Because AppleTalk data packets often contain zone names, AURP provides no means of remapping zone names. When importing or exporting zone names, an exterior router should not modify them in any way. On a very large internet, zone names may become unmanageable. Therefore, an administrator should use domain-specific prefixes-such as Engineering or Sales-for zone names on such an internet. The use of a third-party hierarchical Chooser also might simplify zone-name management. Hop-Count Reduction Generally, an exterior router increases the hop count in the DDP header of an AppleTalk data packet by at least one when it forwards the packet across a tunnel. Once a packet traverses 15 routers-either local routers or exterior routers-its hop count exceeds the maximum. Thus, when an exterior router receives a packet through its tunneling port, it should examine that packet's DDP hop count before forwarding the packet. If the exterior router receives a packet with a hop count of 15 hops, it does not forward the packet to another router, but discards the packet. When a tunnel or point-to-point link connects AppleTalk internets, the distance that a packet must traverse can easily exceed 15 hops. A network administrator might need full connectivity between two internets at a distance exceeding 15 hops. If the distance across an exterior router's local internet is already at or near the 15-hop limit, the exterior router must reduce the perceived distance that a packet must traverse to allow the packet to reach a destination at a distance that exceeds 15 hops. To overcome DDP's 15-hop limit, an exterior router reduces the hop count in the DDP header of an Apple data packet received through a tunnel before forwarding the packet into its local AppleTalk internet. An exterior router should reduce the hop count only by the number of hops necessary to allow the packet to reach its destination without exceeding the hop-count limit. When an exterior router receives a packet through the tunnel, it examines the routing-table entry for that packet's destination network to deter